CVE-2026-113504

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.

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.