CVE-2025-68438

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.