Podatności Apache Airflow

Apache Airflow 3.3.1 zawiera niekompletną poprawkę CVE-2026-67260 — sprawdzenie typu wartości next_kwargs wykonywane jest dopiero po deserializacji całego ładunku, co pozwala na uruchomienie konstruktorów dozwolonych klas w procesie schedulera. Autor DAG-a może wywołać wykonanie kodu w schedulerze i serwerze API bez niestandardowej konfiguracji; wersje przed 3.3.0 nie są podatne.

Scheduler Apache Airflow w pełni deserializuje wartości XCom zapisane przez kod zadania podczas oceny zależności zadań. Autor DAG-a kontrolujący zawartość XCom może więc wpływać na dane deserializowane w procesie schedulera, wykraczając poza udokumentowane uprawnienia.

CLI Apache Airflow zapisuje argumenty w logu audytowym, ale maskuje sekrety według pozycji argumentu, przez co niektóre obsługiwane formy poleceń pozostawiają sekrety w postaci jawnej, np. końcowe `--description` w poleceniach Variable, `--conn-extra` oraz wbudowane `--password` w poleceniach `airflow keycloak-auth-manager`. Użytkownik, który może czytać zdarzenia audytowe, ale nie ma dostępu do Variable i Connection, może odczytać te wartości przez API dziennika zdarzeń.

Apache Airflow odtwarzał pola alertów terminów (deadline alerts) przez ogólną deserializację, która importuje i tworzy instancje klasy wskazanej w serializowanym Dagu, w procesach schedulera i serwera API. Autor Daga mógł spowodować utworzenie klas z listy dozwolonych Airflow z kontrolowanymi przez siebie argumentami. Dotyczy to wdrożeń, których Dagi używają deadline alerts; to niekompletna poprawka CVE-2026-45360, która zabezpieczyła tylko pole reference.

Pamięć podręczna sekretów w Task SDK Apache Airflow budowała klucze z nazwy zespołu i identyfikatora sekretu z nieescapowanym separatorem _, co mogło powodować kolizje różnych par (zespół, identyfikator sekretu). W środowiskach wielozespołowych autor Daga mógł odczytać wartość Variable lub Connection innego zespołu, tworząc kolidujący identyfikator sekretu. Dotyczy to tylko wdrożeń z jednocześnie włączonymi core.multi_team = True i secrets.use_cache = True.

CeleryExecutor w Apache Airflow uruchamiał zadania callback (ExecuteCallback, używane dla callbacków deadline-alert) bez walidacji tokenu uwierzytelniania zadania. Każdy mogący zapisywać do brokera Celery mógł zakolejkować sfałszowany callback i wykonać dowolny kod na każdym workerze CeleryExecutor bez poświadczeń Airflow. Dotyczy to wdrożeń używających CeleryExecutor.

Log audytowy Apache Airflow przechowywał wartości sekretów Connection i Variable w postaci jawnej w kolumnie `Log.extra`, ponieważ masker sekretów dopasowywał tylko skonfigurowane nazwy kluczy wrażliwych. Uwierzytelniony użytkownik z niskimi uprawnieniami i dostępem do odczytu API dziennika zdarzeń/audytu — bez wcześniejszego dostępu do danego połączenia lub zmiennej — mógł odczytać te wiersze i odzyskać poświadczenia dosłownie.

Publiczne API Import Errors w Apache Airflow zwracało surowy stos wywołań błędu parsowania każdemu użytkownikowi z uprawnieniem ImportError.can_read, gdy plik powodujący błąd nie miał zarejestrowanego Daga. Ma to miejsce, gdy plik nie parsuje się przed zdefiniowaniem Daga lub gdy wszystkie wcześniej zarejestrowane Dagi zostały usunięte, a błąd parsowania pozostaje. Użytkownicy, którzy nie powinni widzieć szczegółów pliku, mogą odczytać stosy wywołań ujawniające ścieżki plików i kod.

Endpoint wylogowania Apache Airflow próbował unieważnić przedstawiony token po stronie serwera, ale każdy błąd unieważniania był po cichu ignorowany, a wylogowanie nadal zgłaszało sukces. Gdy menedżer uwierzytelniania przekierowuje wylogowanie do zewnętrznego URL (np. FAB lub Keycloak), unieważnienie po stronie serwera jest jedynym mechanizmem unieważniającym token Airflow; zawodziło ono przy błędach bazy danych oraz niezawodnie dla tokenów zewnętrznego wystawcy akceptowanych przez [api_auth] trusted_jwks_url, których identyfikator tokenu jest dłuższy niż 32 znaki. Każdy posiadający kopię tokenu użytkownika sprzed wylogowania mógł go nadal używać wobec API Airflow do wygaśnięcia.

Masker sekretów Apache Airflow przestawał zagłębiać się w struktury zagnieżdżone po pięciu poziomach, więc sekret zarejestrowany w maskerze — np. hasło Connection lub wartość Variable — który pojawiał się głębiej niż pięć kontenerów pod kluczami niewrażliwymi, był wyświetlany w postaci jawnej w logach zadań i renderowanych polach szablonów. Użytkownik, który może czytać logi zadań lub renderowane szablony, ale nie powinien widzieć tych sekretów, mógł je odczytać.

Asynchroniczny test połączenia w Apache Airflow sprawdzał uprawnienia w momencie kolejkowania testu (tylko uprawnienie create, gdy identyfikator połączenia jeszcze nie istniał), ale po zakończeniu testu z commit_on_success zapisywał testowane połączenie pod tym identyfikatorem. Użytkownik uprawniony do tworzenia, ale nie do edycji połączeń, mógł nadpisać połączenie utworzone w międzyczasie przez kogoś innego. Dotyczy to tylko wdrożeń z włączonym niedomyślnym ustawieniem [core] test_connection.

Punkty końcowe API zasobów Apache Airflow zwracały identyfikatory DAG-ów zaplanowanych na zasobie, produkujących lub konsumujących zasób, bez sprawdzania, czy wywołujący może czytać te DAG-i. Uwierzytelniony użytkownik z dostępem do odczytu zasobów mógł poznać identyfikatory DAG-ów, do których nie ma uprawnień.

Endpoint API Apache Airflow do usuwania zakolejkowanych zdarzeń zasobu sprawdzał uprawnienia do edycji DAG-a na podstawie parametru zapytania `dag_id`, ale usuwał zdarzenia ze wszystkich DAG-ów, do których użytkownik miał uprawnienia odczytu. Uwierzytelniony użytkownik z prawem edycji jednego DAG-a i odczytu innych mógł tłumić uruchamiane przez zasoby przebiegi DAG-ów, których nie może edytować. To niekompletna poprawka CVE-2026-75157 — użytkownicy, którzy zaktualizowali do apache-airflow 3.3.2, nadal są podatni i powinni zaktualizować do 3.4.0 lub nowszej.

Masker sekretów Apache Airflow dopasowywał nazwy kluczy wrażliwych tylko w formie snake_case, więc wartości przechowywane pod kluczami camelCase, takimi jak `privateKey`, `connectionString`, `webhookUrl` lub `accessKey` — np. w extra Connection lub Variable — nie były redagowane w logach zadań, renderowanych polach szablonów ani odpowiedziach API. Użytkownik, który może czytać logi zadań lub renderowane szablony, ale nie powinien widzieć tych poświadczeń, mógł je odczytać w postaci jawnej.

API wykonywania zadań Apache Airflow przechowywało wartości XCom zapisane przez zadanie bez sprawdzenia kluczy zastrzeżonych stosowanego w innych miejscach, więc zadanie autora DAG-a mogło zapisać XCom, który przy późniejszym odczycie przez API z włączoną deserializacją powodował utworzenie przez serwer API obiektów z przestrzeni nazw `airflow.*` z argumentami wybranymi przez autora DAG-a. To niekompletna poprawka CVE-2026-59242 — użytkownicy, którzy zastosowali tę poprawkę w apache-airflow 3.3.1, nadal są podatni tą drogą i powinni zaktualizować do 3.4.0 lub nowszej.

Apache Airflow nie odrzucał zastrzeżonych kluczy serializacji w polu `conf` przebiegu DAG-a. Użytkownik uprawniony do uruchomienia DAG-a korzystającego z alertu terminu z asynchronicznym wywołaniem zwrotnym mógł przekazać `conf`, który po przekroczeniu terminu albo wielokrotnie powodował awarię schedulera, albo był odtwarzany w obiekty wewnątrz Triggerera. Zaleca się aktualizację do apache-airflow 3.4.0 lub nowszej.

API połączeń Apache Airflow nie maskowało pola extra `config` dostawcy apprise, które może zawierać dane uwierzytelniające do usług powiadomień. Użytkownik z uprawnieniem do odczytu połączeń mógł je odczytać w postaci jawnej, mimo że Airflow 3 traktuje dane uwierzytelniające połączeń jako tylko do zapisu.

Przykładowy DAG `example_dag_decorator` dostarczany z Apache Airflow walidował adres IP pobrany przez HTTP modułem `ipaddress` w Pythonie, a następnie umieszczał go w poleceniu powłoki. Moduł `ipaddress` akceptuje identyfikatory stref IPv6 zawierające dowolne znaki, więc gdy przykładowe DAG-i są ładowane (`load_examples` włączone), użytkownik mogący uruchomić ten DAG z własnym parametrem `url` mógł wskazać serwer, którego odpowiedź wstrzykuje polecenia powłoki wykonywane na workerze. To niekompletna poprawka CVE-2025-54941 — użytkownicy, którzy zaktualizowali dla CVE-2025-54941, powinni zaktualizować ponownie. Zaleca się aktualizację do apache-airflow 3.4.0 lub nowszej albo wyłączenie przykładowych DAG-ów (`load_examples = False`), co jest zalecane w środowisku produkcyjnym.

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

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

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.

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.

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.