CVE-2026-68971
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 26 - wyżej niż 26% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może uzyskać nieautoryzowany dostęp do danych i operacji w systemie, co może prowadzić do naruszenia poufności i integralności danych oraz zakłócenia działania.
Rekomendacja
Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszej, która rozwiązuje problem z zespołem Dagów w obu miejscach.
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-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)
Apache Airflow's asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:<team>` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

