CVE-2026-86468

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.

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.