CVE-2025-66236
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 24 - wyżej niż 24% wszystkich znanych CVE
Streszczenie
Przed Airflow 3.2.0 nie było jasne, że bezpieczne wdrożenia Airflow wymagają od Deployment Managera podjęcia odpowiednich działań i zwrócenia uwagi na szczegóły bezpieczeństwa oraz model bezpieczeństwa Airflow. Niektóre założenia Deployment Managera nie były wystarczająco jasne lub wyraźne. Model bezpieczeństwa, izolacja obciążeń i szczegóły uwierzytelniania JWT są teraz opisane bardziej szczegółowo.
Ocena ryzyka
Organizacje wdrażające Airflow mogą mieć nieświadomie niebezpieczną konfigurację z powodu niejasnych założeń dotyczących bezpieczeństwa. Może to prowadzić do naruszenia izolacji ról i nieautoryzowanego dostępu.
Rekomendacja
Zaktualizuj Airflow do wersji 3.2.0, która naprawia ten problem i zawiera ulepszenia bezpieczeństwa. Zapoznaj się z dokumentacją dotyczącą modelu bezpieczeństwa, izolacji obciążeń i uwierzytelniania JWT.
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)
Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow's intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4]. [1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html [2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html [3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html [4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/ Users are recommended to upgrade to version 3.2.0, which fixes this issue.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS