CVE-2026-75158

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.

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