CVE-2026-82355
ŚrednieCVSS 4.2Streszczenie
W Apache Airflow 3.3.0 i 3.3.1 istnieje problem z priorytetem uwierzytelniania: gdy żądanie zawiera zarówno ciasteczko sesji, jak i token Bearer, Airflow używa ciasteczka, ignorując token. Powoduje to wykonanie żądania jako użytkownik z ciasteczka, a nie z tokena, oraz błędne zapisy w audycie.
Ocena ryzyka
Możliwość podszywania się pod innego użytkownika, jeśli atakujący umieści ciasteczko w przeglądarce ofiary, co może prowadzić do nieautoryzowanych działań i błędnej rejestracji zdarzeń.
Rekomendacja
Zaktualizuj Apache Airflow do wersji 3.3.2 lub nowszej, która rozwiązuje ten problem.
Inne podatności w Apache Airflow
Zobacz wszystkie- CVE-2026-75158Średnie
API /assets/events w Apache Airflow zwraca zdarzenia zasobów dla wszystkich DAG-ów, bez filtrowania według uprawnień użytkownika. Uwierzytelniony użytkownik z dostępem do odczytu zasobów może wyliczyć zdarzenia, w tym identyfikatory DAG-ów, tasków, runów i znaczniki czasu, dla DAG-ów, do których nie ma uprawnień. Nawet liczba zdarzeń ujawnia istnienie ukrytych DAG-ów.
- CVE-2025-68438Wysokie
W Apache Airflow przed wersją 3.1.6, gdy renderowane pola szablonów w Dag przekraczają [core] max_templated_field_length, wrażliwe wartości mogły być ujawniane w postaci czystego tekstu w interfejsie Rendered Templates UI. Stało się tak, ponieważ serializacja tych pól używała instancji maskującej sekrety, która nie zawierała wzorców mask_secret() zarejestrowanych przez użytkownika, więc sekrety nie były niezawodnie maskowane przed obcięciem i wyświetleniem. Zaleca się aktualizację do wersji 3.1.6 lub nowszej.
- CVE-2026-86473Krytyczne
W Apache Airflow endpoint wylogowania Core API unieważnia wyłącznie token sesji przekazany w cookie _token. Jeśli klient wylogowuje się, przekazując poświadczenie w nagłówku Authorization typu bearer, endpoint zwraca standardową odpowiedź wylogowania, ale niczego nie unieważnia, więc token pozostaje ważny do czasu wygaśnięcia (domyślnie 24 godziny, wartość konfigurowalna).
- CVE-2026-33264Krytyczne
Podatność w metodzie `BaseSerialization.deserialize()` umożliwia nieograniczone wywołanie `import_string()` na ścieżkach klas kontrolowanych przez atakującego. Gdy Scheduler lub API Server ładuje serializowany DAG, autor DAG-a może osadzić złośliwy trigger, co prowadzi do zdalnego wykonania kodu na tych procesach, naruszając granicę bezpieczeństwa Airflow.
- CVE-2026-42252Krytyczne
Dokumentacja Apache Airflow zawierała przykład kodu `BashOperator` bez odpowiedniego cytowania, co umożliwiało wstrzyknięcie metaznaków powłoki przez pole `conf` w API wyzwalania DAG. Autoryzowany użytkownik z uprawnieniem `Dag.can_trigger` mógł wykonać dowolne polecenia na workerze.
- CVE-2020-13927KrytyczneAktywnie exploitowane
Poprzednie domyślne ustawienie eksperymentalnego API Airflow zezwalało na wszystkie żądania API bez uwierzytelniania, co stwarza ryzyko bezpieczeństwa dla użytkowników, którzy tego nie zauważyli. Od Airflow 1.10.11 domyślnie wszystkie żądania są odrzucane; istniejące instalacje wymagają zmiany konfiguracji na [api]auth_backend = airflow.api.auth.backend.deny_all.
- CVE-2020-11978WysokieAktywnie exploitowane
W Apache Airflow w wersjach 1.10.10 i starszych wykryto podatność na wstrzyknięcie kodu/komend w jednym z przykładowych DAG-ów dołączanych do Airflow. Uwierzytelniony użytkownik może wykonać dowolne komendy jako użytkownik uruchamiający worker/scheduler Airflow. Jeśli przykłady są wyłączone (load_examples=False), podatność nie występuje.
- CVE-2026-75157Niskie ryzyko· EPSS 7%
Punkty końcowe DELETE dla zdarzeń kolejkowanych zasobów w Apache Airflow sprawdzały uprawnienie osi Dag wywołującego z użyciem READ zamiast EDIT. Każdy uwierzytelniony użytkownik z prawem odczytu Daga mógł usuwać jego zakolejkowane zdarzenia zasobów, po cichu wyłączając harmonogramowanie wyzwalane zasobami.
- CVE-2026-68971Średnie
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.
- CVE-2026-68970Średnie
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.
Oryginalny opis (angielski, źródło NVD)
When a request to the Airflow core API carries both a session cookie and an explicit `Authorization: Bearer` token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented. Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable. Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation. Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.