Katalog podatności CVE

Uwierzytelniony użytkownik bez uprawnień do odczytu repozytorium może uzyskać dostęp do metadanych pakietów w określonych warunkach.

Nieuwierzytelniony użytkownik może uzyskać dostęp do ograniczonych artefaktów w JFrog Artifactory w określonych warunkach.

W Apache Airflow, endpoint materializacji zasobów (`POST /api/v2/assets/{asset_id}/materialize`) oraz sprawdzanie wyników XCom w `wait_dag_run_until_finished` autoryzowały docelowy Dag bez uwzględnienia zespołu, w przeciwieństwie do innych miejsc autoryzacji. W trybie wielozespołowym z menedżerem autoryzacji uwzględniającym zespoły, uwierzytelniony użytkownik z jednego zespołu mógł wywołać uruchomienia Dagów należących do innego zespołu, podając własne `dag_run_id` i `conf`, oraz mógł odczytać wartości XCom innego zespołu. Deployments używające menedżera FAB nie są dotknięte, ponieważ nie obsługuje on wielu zespołów. Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszej.

W Apache Airflow, Task SDK nie maskował zawartości Zmiennej, której wartość JSON jest listą, więc sekrety przechowywane w tej formie pojawiały się w postaci jawnej w logach zadań i w interfejsie Rendered Templates. Maskowanie było stosowane tylko, gdy zdeserializowana wartość była stringiem lub słownikiem; lista na najwyższym poziomie nie pasowała do żadnego z tych przypadków i była zwracana bez maskowania. Każdy uwierzytelniony użytkownik, który może czytać logi lub wyrenderowane szablony zadania odwołującego się do takiej Zmiennej, mógł odzyskać wartości, bez specjalnej konfiguracji. Jest to odpowiednik CVE-2026-59244 dla list, którego poprawka obejmowała tylko przypadek słownika, więc wdrożenia, które zaktualizowały się w odpowiedzi na to ostrzeżenie, pozostają dotknięte i muszą zaktualizować się ponownie. Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszej.

Podatność w Apache Airflow powoduje zapisywanie wartości zmiennych (Variables) oraz zawartości pola `extra` w połączeniach (Connections) do dziennika audytowego w postaci jawnego tekstu, gdy są one przesyłane przez punkty końcowe zbiorcze (`PATCH /api/v2/variables` i `PATCH /api/v2/connections`). Maskowanie w dzienniku audytowym rozpoznaje tylko pola najwyższego poziomu, a żądanie zbiorcze zagnieżdża encje dwa poziomy niżej, więc maskowanie nie jest stosowane. Każdy uwierzytelniony użytkownik z dostępem do odczytu dziennika audytowego (niekoniecznie mający uprawnienia do odczytu Variables lub Connections) może odzyskać te sekrety w oryginalnej formie, a kopia `extra` połączenia jest przechowywana w logu bez szyfrowania, podczas gdy tabela połączeń szyfruje ją.

Uwierzytelniony użytkownik z niskimi uprawnieniami może uzyskać dostęp do ograniczonych informacji wsparcia technicznego w określonych warunkach.

W Apache Airflow backend sekretów oparty na zmiennych środowiskowych rozwiązywał połączenia lub zmienne przypisane do zespołu z niewłaściwego zakresu zespołu. Zabezpieczenie zapobiegające temu działało tylko wtedy, gdy nie podano zakresu zespołu, a jego wzorzec nie mógł dopasować nazwy zespołu zawierającej podkreślenie. W trybie wielozespołowym uwierzytelniony użytkownik jednego zespołu mógł rozwiązać połączenie innego zespołu i uwierzytelnić się na zewnątrz przy użyciu poświadczeń tego zespołu.

W określonych samodzielnie hostowanych konfiguracjach Helm, wygenerowane prywatne klucze TLS mogą być przechowywane w renderowanych manifestach, dostępnych dla wysoce uprzywilejowanych lokalnych użytkowników.

W wersjach WhatsUp Gold przed 2026.0.2, uprzywilejowany atakujący może zapisywać dowolne pliki w lokalizacji dostępnej przez sieć na serwerze hosta.

W wersjach WhatsUp Gold przed 2026.0.2, uprzywilejowany atakujący może utworzyć akcję LogToFile z dowolnym rozszerzeniem pliku w katalogu głównym IIS.

W wersjach WhatsUp Gold przed 2026.0.2, luka w autoryzacji w API Scheduled Reports pozwala każdemu uwierzytelnionemu użytkownikowi na wywoływanie ograniczonych akcji.

API konfiguracji w Apache Airflow nie maskował wrażliwych wartości konfiguracyjnych o zakresie zespołu we wdrożeniach wielozespołowych. Gdy administrator włączył tryb wielozespołowy i udostępnił API konfiguracji, uwierzytelniony użytkownik z rolą Viewer mający tylko dostęp do odczytu konfiguracji — bez wcześniejszego dostępu do sekretu — mógł odczytać adres URL brokera Celery o zakresie zespołu, w tym osadzone poświadczenia, w postaci jawnego tekstu, podczas gdy równoważna opcja globalna była poprawnie maskowana. Masker sekretów dopasowywał tylko podstawowe nazwy sekcji i opcji i nie normalizował sekcji z prefiksem zespołu przed sprawdzeniem wrażliwości (CWE-200). Jest to odrębne obejście maskera od CVE-2026-48828 i CVE-2026-48892: wdrożenia, które zaktualizowały się do apache-airflow 3.3.0 w celu rozwiązania tych problemów, pozostają dotknięte tym wariantem o zakresie zespołu. Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszego, który normalizuje sekcje z prefiksem zespołu przed maskowaniem.

Masker sekretów w Apache Airflow nie maskował wartości zmiennych `var.json`, których wartość jest słownikiem, w interfejsie Rendered Templates — wartość słownika nie przeszła kontroli `isinstance(str)` — więc sekret przechowywany jako zmienna JSON i odwoływany w szablonie przez `var.json` był wyświetlany w postaci jawnego tekstu każdemu użytkownikowi mającemu dostęp do widoku Rendered Templates danego zadania. Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszego, który maskuje zagnieżdżone wartości zmiennych niezależnie od typu.

W Apache Airflow, endpoint XCom `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` przekazuje łańcuch znaków do `BaseXCom.deserialize_value` bez zabezpieczenia `_check_forbidden_xcom_keys`, co pozwala uwierzytelnionemu użytkownikowi z dostępem do zapisu i odczytu XCom na tworzenie dowolnych klas `airflow.*` na serwerze API (CWE-502). Uwierzytelniony użytkownik, który może zapisać wartość XCom i odczytać ją z `deserialize=true`, wywołuje niebezpieczną instancję. Zalecana jest aktualizacja do apache-airflow 3.3.1 lub nowszej, która odrzuca zarezerwowane klucze serializacji XCom przesłane jako literały JSON.

W Apache Airflow, masker sekretów ukrywa wartości przechowywane pod wrażliwymi nazwami kluczy, gdy są wyświetlane w interfejsie użytkownika. Limit głębokości rekurencji maskera nie schodził do wartości zagnieżdżonych w liście, krotce lub zbiorze poza tym limitem, więc zmienna Airflow zawierająca tak głęboko zagnieżdżoną wartość była wyświetlana bez maskowania w interfejsie zmiennych. Ekspozycja ogranicza się do interfejsu użytkownika: każdy uwierzytelniony użytkownik, który widzi zmienną w interfejsie, może już odczytać jej pełną wartość przez API REST zmiennych, więc nie ujawnia to danych, których użytkownik nie mógłby w inny sposób uzyskać — maskowanie jest obroną przed podglądaniem ekranu, a nie granicą kontroli dostępu. Jest to niekompletna poprawka po CVE-2026-42358, której poprawka uczyniła tylko przechodzenie po słowniku nieograniczonym; listy, krotki i zbiory poza limitem głębokości pozostały niezmaskowane w interfejsie. Wdrożenia, które zastosowały poprawkę CVE-2026-42358, powinny również dokonać aktualizacji, aby rozwiązać ten przypadek. Zalecana jest aktualizacja do apache-airflow 3.3.1 lub nowszej.

W GNU linkerze (ld) z pakietu binutils wykryto wiele podatności Use-After-Free w funkcji add_archive_element. Problem wynika z nieprawidłowego zwalniania obiektu BFD przez plugin_maybe_claim(), co pozostawia wiszące wskaźniki, które są później używane w trzech miejscach. Podatność jest wyzwalana, gdy aktywne są wtyczki LTO, a plik wejściowy nie jest częścią archiwum.

Podatność SSRF w funkcji synchronizacji zdalnych instancji w Vulnerability-Lookup. Adresy zdalnych instancji były walidowane tylko pod kątem podstawowej składni URL, a następnie serwer wykonywał żądania do nich bez ograniczeń sieciowych, podążając za przekierowaniami bez ponownej walidacji. Uwierzytelniony administrator z uprawnieniem admin:access mógł skonfigurować instancję wskazującą na wewnętrzne, pętlowe, link-local lub cloud metadata usługi.

Podatność w Vulnerability-Lookup pozwala nieaktywnym lub niepotwierdzonym kontom subskrybować strumienie SSE przez endpoint /pubsub/subscribe/<topic>. Autoryzacja opierała się wyłącznie na nagłówku X-API-KEY, bez weryfikacji stanu konta. Atakujący może utworzyć konto i natychmiast uzyskać dostęp do strumieni, które powinny być dostępne tylko dla aktywnych i potwierdzonych użytkowników.

W aplikacji Vulnerability-Lookup wykryto podatność na trwały atak XSS w filtrze Jinja render_tag_badges, używanym do wyświetlania tagów referencyjnych powiązanych z rekordami podatności. Wartości z tablicy containers.cna.references[].tags[] były bezpośrednio wstawiane do elementów HTML badge i opakowywane w markupsafe.Markup, co omijało automatyczne kodowanie HTML w Jinja. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania rekordów podatności (np. vulnerability:create lub vulnerability:modify) mógł przesłać przez API CNA spreparowany tag zawierający dowolny HTML lub JavaScript.