CVE-2026-45426
NiskieCVSS 3.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 27 - wyżej niż 27% wszystkich znanych CVE
Streszczenie
W Apache Airflow, aby wykorzystać podatność, atakujący musi być już uwierzytelnionym workerem Airflow posiadającym ważny JWT serwera logów wystawiony dla co najmniej jednego Daga. Serwer logów Airflow autoryzował tokeny JWT względem identyfikatorów Dag, stosując Pythonowe `str.lstrip()` do żądanego segmentu ścieżki podczas weryfikacji claimu `sub` w JWT. `str.lstrip()` usuwa dowolny znak z *zestawu* znaków z lewej strony (nie prefiks), więc JWT wystawiony dla Daga o nazwie np. `dag_a` autoryzowałby dostęp do logów każdego innego Daga, którego nazwa zaczynała się od dowolnego podzbioru znaków `{d, a, g, _}` (np. `dag_attacker`, `aaaa_target`, `_dag_secret`). Taki uwierzytelniony worker mógł wyliczyć i odczytać logi workerów innych Dagów, których nazwy dzieliły tę klasę znaków, wyciekając dane wyjściowe zadań i ślady błędów poza udokumentowaną granicę izolacji na Dag.
Ocena ryzyka
W środowiskach wielodziałowych, gdzie izolacja logów na Dag jest kluczowa, podatność umożliwia nieautoryzowany dostęp do logów innych Dagów, co może prowadzić do wycieku wrażliwych danych, takich jak dane wyjściowe zadań i komunikaty błędów.
Rekomendacja
Zaleca się aktualizację Apache Airflow do wersji 3.2.2 lub nowszej, która naprawia tę podatność poprzez prawidłową walidację prefiksu ścieżki zamiast użycia `str.lstrip()`.
Inne podatności w Apache Airflow
Zobacz wszystkie- 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-82355Średnie
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.
- 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-2026-75157Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
Exploitation requires the attacker to already be an authenticated Airflow worker holding a valid Log-server JWT issued for at least one Dag. Apache Airflow's Log server authorized JWT tokens against Dag IDs by applying Python's `str.lstrip()` to the requested path segment when verifying the JWT's `sub` claim. `str.lstrip()` strips any of a *set* of characters from the left (not a prefix), so a JWT issued for a Dag named e.g. `dag_a` would authorize log access to any other Dag whose name began with any subset of the characters `{d, a, g, _}` (e.g. `dag_attacker`, `aaaa_target`, `_dag_secret`). Such an authenticated worker could enumerate and read worker logs of other Dags whose names happened to share that character-class prefix, leaking task output and error traces beyond the documented per-Dag isolation boundary. Affects deployments relying on per-Dag log-access scoping (multi-team, shared-executor, shared-worker topologies). Users are advised to upgrade to `apache-airflow` 3.2.2 or later.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS