Podatności Apache Airflow

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.

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.

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.

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ą.

API Backfill w Apache Airflow autoryzował żądanie względem identyfikatora Dag podanego przez wywołującego, gdy segment ścieżki `backfill_id` nie mógł zostać sparsowany. Zależność autoryzacji parsowała go funkcją `int()`, podczas gdy procedura obsługi trasy parsowała go jako pydantic `NonNegativeInt`, który akceptuje wartości odrzucane przez `int()` (`1.0` jest konwertowane na `1`); FastAPI rozwiązuje zależności przed walidacją punktu końcowego, więc działały na różnych Dagach. Uwierzytelniony użytkownik z uprawnieniami edycji dowolnego pojedynczego Dag mógł odczytywać, wstrzymywać i anulować backfille należące do innych Dagów, w tym przenosić kolejkowane uruchomienia innego Dag do stanu `failed`. Nie jest wymagana żadna niestandardowa konfiguracja, a identyfikatory backfill są sekwencyjne, więc znalezienie celu jest trywialne. Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszego, który parsuje identyfikator backfill tym samym typem, który deklarują trasy.

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.

Task SDK w Apache Airflow odtwarzał obiekt `Callback` z danych serializowanych, ponownie uruchamiając jego konstruktor, który importuje moduł o nazwie ze ścieżki przechowywanego callbacka. Ponieważ `SyncCallback` jest klasą Airflow, przechodzi domyślną listę dozwolonych klas `allowed_deserialization_classes`, więc zaostrzenie tego ustawienia nie pomaga. Autor Dag — który kontroluje `next_kwargs` instancji zadania przez API wykonywania zadań — może spowodować import dowolnego modułu w procesie schedulera, gdy scheduler przeszukuje wartości z `awaiting_input` i deserializuje tę wartość. Nie jest wymagana żadna niestandardowa konfiguracja; przeszukiwanie działa bezwarunkowo. Wersje przed 3.3.0 nie są dotknięte: klasa istniała, ale przeszukiwanie schedulera, które do niej dociera, nie istniało. Jest to oddzielna ścieżka kodu od CVE-2026-58076 i CVE-2026-67260, które obejmują inne gadżety prowadzące do deserializacji — zastosowanie którejkolwiek z tych poprawek nie rozwiązuje tego problemu. Zaleca się aktualizację do apache-airflow 3.3.1 lub nowszego.

Apache Airflow 3.3.0 zawiera podatność w mechanizmie przetwarzania zadań typu human-in-the-loop, gdzie deserializacja next_kwargs bez listy dozwolonych klas pozwala autorowi DAG-a na import dowolnego modułu i utworzenie obiektu w procesie schedulera lub zakończenie jego działania. Wymagana jest aktualizacja do wersji 3.3.1 lub nowszej.

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.

Warstwa serializacji Apache Airflow rekonstruuje węzły wyjątków, wywołując `import_string()` na nazwie klasy pochodzącej z serializowanego obiektu i tworząc jej instancję z argumentami z tego samego obiektu, bez ograniczeń co do tego, co może zostać zaimportowane. Atakujący autor Dag może umieścić w `executor_config` wartość, która spowoduje zaimportowanie i wywołanie dowolnego wywoływalnego obiektu, np. `subprocess.check_output` lub `builtins.eval`. Kod wykonuje się w Schedulerze oraz w serwerze API, które zgodnie z modelem bezpieczeństwa Airflow nigdy nie powinny wykonywać kodu autora Dag.

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 Apache Airflow przed wersją 3.3.0, endpointy REST API szczegółów i listy instancji zadań zwracały argumenty wyzwalacza (trigger kwargs) odroczonego zadania bez maskowania. Oznacza to, że jeśli odroczony operator przekazał sekret (np. klucz API dostawcy) do swojego wyzwalacza, każdy uwierzytelniony użytkownik z dostępem do odczytu instancji zadania w zakresie DAG mógł odczytać ten sekret w postaci jawnego tekstu, dopóki zadanie było odroczone.

Przed wersją 3.3.0 Apache Airflow, użytkownik z uprawnieniami do odczytu jednego DAG-a mógł ujawnić kod źródłowy innych DAG-ów znajdujących się w tym samym pliku. Endpoint API `GET /api/v2/dagSources/{dag_id}` oraz odpowiadający mu widok w interfejsie użytkownika zwracały cały plik źródłowy bez maskowania DAG-ów, do których odczytu osoba nie była upoważniona.

Podatność w Apache Airflow ujawniała nadpisania sekretów backendu (zmienne środowiskowe) jako opcje konfiguracji, które nie były maskowane. Uwierzytelniony użytkownik z uprawnieniami do odczytu konfiguracji mógł pobrać jawne dane uwierzytelniające (np. role_id, secret_id) z API konfiguracji.

W Apache Airflow w punkcie końcowym `/ui/dependencies` harmonogramu wykryto błąd, który ujawnia identyfikatory Dagów (Dag IDs) przez pola `dep.source` i `dep.target` w zależnościach wyzwalaczy i sensorów. Uwierzytelniony użytkownik interfejsu z uprawnieniami do odczytu niektórych Dagów może wyliczyć identyfikatory innych Dagów, do których nie ma dostępu. Jest to pozostałość po poprawce CVE-2026-28563, która filtrowała tylko klucz najwyższego poziomu, ale nie objęła pól źródła i celu zależności.

Podatność w API Bulk Variables Apache Airflow powoduje, że redaktor nie otrzymuje klucza zmiennej, przez co kontrola `should_hide_value_for_key` (aktywowana dla nazw kluczy z sufiksami `_password`, `_token`, `_secret`) nie działa dla wartości zmiennych w formacie JSON. Uwierzytelniony użytkownik z uprawnieniami do odczytu zmiennych może uzyskać jawne wartości z JSON-owych zmiennych, których klucz normalnie wywołałby ukrycie.

Podatność w Apache Airflow w operatorach Google Cloud Storage (GCS) do SFTP i transformacji plików pozwala na zapis plików poza docelowym katalogiem. Atakujący z dostępem do zapisu w źródłowym buckecie GCS może stworzyć obiekt o nazwie zawierającej segmenty `..`, co skutkuje nadpisaniem dowolnych plików na serwerze SFTP lub hoście roboczym.

W Apache Airflow z KubernetesExecutor odkryto błąd, w którym tokeny JWT używane przez pody workerów do uwierzytelniania w Execution API były przekazywane jako argumenty wiersza poleceń, widoczne w specyfikacji poda. Uwierzytelniony użytkownik z dostępem tylko do odczytu do klastra Kubernetes (np. `pods/get`) mógł przechwycić JWT z wyjścia `kubectl describe pod` i wywoływać operacje zmieniające stan Execution API.

W Apache Airflow, EmailOperator i pomocnicze funkcje `airflow.utils.email` nawiązują połączenia SMTP STARTTLS bez weryfikacji certyfikatu zdalnego, gdy używane jest `smtp_starttls=True` bez `smtp_ssl`. Atakujący w pozycji MITM może przedstawić samopodpisany certyfikat i przechwycić dane uwierzytelniające SMTP oraz treść wiadomości.

Błąd w obsłudze wylogowania w Apache Airflow (FabAuthManager i KeycloakAuthManager) powoduje, że wcześniej wydane tokeny JWT pozostają ważne po wylogowaniu użytkownika, umożliwiając atakującemu kontynuowanie uwierzytelnionych wywołań API.

Apache Airflow przed wersją 3.2.2 ma lukę w punkcie końcowym GET /api/v2/eventLogs/{event_log_id}, który pobiera wpisy dziennika audytu bezpośrednio po ID numerycznym, bez sprawdzania zakresu per-Dag. Uwierzytelniony użytkownik z uprawnieniami do odczytu dziennika audytu dla jednego Daga może odczytać wpisy dla innych Dagów poprzez zgadywanie lub enumerację ID.

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.

W Apache Airflow wykryto podatność w dekoderze referencji terminarza (`SerializedCustomReference.deserialize_reference`), który importuje i wykonuje dowolne ścieżki klas z serializowanego stanu DAG-a bez listy dozwolonych. Autor DAG-a, którego kod dociera do schedulera (domyślnie w jednohostowych wdrożeniach), może osadzić niestandardową `DeadlineReference` wskazującą na moduł atakującego, co powoduje zaimportowanie i utworzenie instancji klasy z aktywną sesją SQLAlchemy.

W Apache Airflow, obsługa pól renderowanych powodowała pomijanie maskowania zagnieżdżonych kluczy wrażliwych (np. password, token) gdy długość pola przekraczała limit. Uwierzytelniony użytkownik z uprawnieniami do odczytu mógł uzyskać jawne wartości sekretów.

Podatność w Apache Airflow w punkcie końcowym PATCH XCom pozwalała uwierzytelnionym użytkownikom z uprawnieniami do zapisu XCom na ustawianie wpisów pod zastrzeżonymi nazwami kluczy (np. return_value), co w połączeniu z akceptowaniem serializowanych ładunków traktowanych jako kod przez deserializator triggerera umożliwiało zdalne wykonanie kodu (RCE) na triggererze. Jest to obejście poprawki CVE-2026-33858, która dodała walidację FORBIDDEN_XCOM_KEYS tylko na ścieżce POST, a nie PATCH.

W Apache Airflow, masker odpowiedzi zmiennych (Variables) pomijał maskowanie zagnieżdżonych kluczy wrażliwych (np. password, token) gdy głębokość zagnieżdżenia przekraczała limit rekurencji. Uwierzytelniony użytkownik z uprawnieniami do odczytu mógł uzyskać jawne wartości sekretów.

W Apache Airflow wykryto błąd w zbiorczym API instancji zadań (PATCH/DELETE /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances), który powodował, że autoryzacja była sprawdzana względem dag_id z ścieżki URL, podczas gdy operacje wykonywane były na dag_id/dag_run_id z pól encji w ciele żądania. Uwierzytelniony użytkownik z uprawnieniami do edycji jednego DAG mógł modyfikować stan instancji zadań w innym DAG, podając autoryzowany DAG w ścieżce URL a docelowy DAG w ciele żądania. Problem dotyczy wdrożeń polegających na izolacji stanu instancji zadań między zespołami na podstawie uprawnień do DAG. Łatka dostępna w wersji apache-airflow 3.2.2.

Apache Airflow w wersjach przed 3.2.2 ma podatność w `JWTRefreshMiddleware`, gdzie ciasteczko JWT nie ma flagi `Secure`. W konfiguracjach z proxy HTTPS (np. nginx) ciasteczko może zostać przechwycone przez atakującego w sieci (Wi-Fi MITM) i użyte do nieautoryzowanego dostępu do API.

Apache Airflow przed wersją 3.2.2 ma lukę w punktach końcowych partitioned_dag_runs w interfejsie UI, które egzekwują tylko kontrolę dostępu na poziomie zasobu, a nie autoryzację per-Dag. Uwierzytelniony użytkownik z globalnym uprawnieniem Asset:read może wyliczyć stan partycji, konfigurację harmonogramu i powiązania zasobów dla Dagów, do których nie ma uprawnień odczytu.

Endpoint structure_data w interfejsie Airflow UI zwracał węzły grafu zależności dla połączonych DAG-ów bez sprawdzania, czy wywołujący ma uprawnienia do odczytu tych DAG-ów. Uwierzytelniony użytkownik UI/API upoważniony do jednego DAG-a mógł wyliczyć identyfikatory i metadane zależności dla innych DAG-ów, do których nie miał dostępu.

W Apache Airflow wykryto błąd w ścieżce przekierowania logowania, który pozwalał uwierzytelnionym użytkownikom na tworzenie adresów URL omijających sprawdzenie `is_safe_url`. Umożliwiało to przekierowanie z zaufanej domeny Airflow do kontrolowanej przez atakującego lokalizacji.

Autor DAG-a w Apache Airflow może wykorzystać dowiązania symboliczne lub sekwencje `..` w identyfikatorze zadania, aby odczytać lub nadpisać dowolne pliki poza skonfigurowanym katalogiem dzienników, jeśli folder dzienników roboczych jest współdzielony z serwerem API.

Błąd w punkcie końcowym REST API GET `/api/v2/connections/{connection_id}` w Apache Airflow umożliwia uwierzytelnionemu użytkownikowi z uprawnieniem Connection-read odczytanie sekretów przechowywanych w polu `extra` połączenia, jeśli nazwy pól nie znajdują się na liście dozwolonych do redakcji. Dotyczy to wdrożeń przechowujących dane uwierzytelniające w polu `extra` i przyznających dostęp Connection-read wielu użytkownikom.

Od wersji 5.2.0, przy użyciu trybu odroczonego z plikiem konfiguracyjnym Kubernetes do uwierzytelniania, Airflow worker serializuje ten plik jako słownik i przechowuje go w metadanych bez szyfrowania. W wersjach 2.3.0-2.6.0 słownik jest dodatkowo logowany w postaci jawnego tekstu w usłudze triggerer. Pozwala to osobie z dostępem do metadanych lub logów na uzyskanie pliku konfiguracyjnego i dostęp do klastra Kubernetes.

Podatność na fikcję sesji pozwalała uwierzytelnionemu użytkownikowi na kontynuowanie dostępu do serwera WWW Airflow, nawet po zresetowaniu hasła przez administratora, aż do wygaśnięcia sesji użytkownika. Wprowadzona poprawka unieważnia istniejące sesje użytkownika po zresetowaniu hasła, gdy używany jest backend sesji oparty na bazie danych.

Apache Airflow w wersjach przed 2.7.0 zawiera podatność, którą może wykorzystać uwierzytelniony użytkownik posiadający uprawnienia do edytowania połączeń. Umożliwia to dostęp do informacji o połączeniach oraz wykorzystanie funkcji testowania połączenia, co może prowadzić do stanu odmowy usługi (DoS) na serwerze.

Podatność w Apache Airflow umożliwia uwierzytelnionym użytkownikom ominięcie niektórych ograniczeń, co pozwala na wykonywanie kodu w kontekście serwera WWW oraz na dostęp do określonych DAG-ów, do których użytkownik normalnie nie ma dostępu. Funkcja 'Run Task' została uznana za niebezpieczną i usunięta w wersji 2.6.0.

Apache Airflow w wersjach przed 2.6.3 ma podatność, która pozwala uwierzytelnionemu użytkownikowi na wykorzystanie spreparowanego wejścia, co może spowodować zawieszenie bieżącego żądania.

Apache Airflow w wersjach przed 2.6.3 jest podatny na lukę, która umożliwia nieautoryzowany dostęp do DAG-a poprzez URL.

W Apache Airflow występuje podatność, która może ujawniać potencjalnie wrażliwe wartości użytkownikom w określonych sytuacjach. Problem ten dotyczy wersji od 2.5.0 do przed 2.6.2.