Airflow Amazon provider CVE-2026-86467: SAML login CSRF w AWS auth managerze. Poprawka 9.38.0 działa, dopóki nikt nie włączy flagi obejścia

19 października projekt Apache Airflow ogłosił CVE-2026-86467 w pakiecie apache-airflow-providers-amazon. AWS auth manager z logowaniem SAML nie sprawdzał, czy odpowiedź dostawcy tożsamości odpowiada na logowanie rozpoczęte w tej samej przeglądarce. Skutek: ofiarę można po cichu zalogować do Airflow na konto napastnika. To nie jest przejęcie konta ofiary, ale wszystko, co ofiara potem zrobi, trafia do sesji kontrolowanej przez kogoś innego. Poprawka jest w wersji 9.38.0 providera, nie w rdzeniu Airflow. Ma też koszt operacyjny: przestaje działać logowanie z kafelka w portalu AWS IAM Identity Center. Przywraca je jedna opcja konfiguracyjna, która według dokumentacji projektu oddaje część ochrony.

Co było zepsute

Opis w PR jest wyjątkowo precyzyjny. Funkcja login() odrzucała identyfikator AuthnRequest, który generuje biblioteka python3-saml, a login_callback() wywoływała przetwarzanie odpowiedzi bez tego identyfikatora. python3-saml sprawdza InResponseTo tylko wtedy, gdy dostanie identyfikator żądania. Kontrola była więc pomijana i akceptowana była każda odpowiedź podpisana przez skonfigurowanego IdP.

Autor poprawki ujmuje sedno jednym zdaniem: podpisana asercja uwierzytelnia tożsamość w odpowiedzi, ale nie mówi, która przeglądarka o nią prosiła. Ten sam problem z drugiej strony opisywałem przy Prowlerze, gdzie poprawny podpis SAML nie chronił przed trafieniem tokenu do złego tenanta, oraz przy Apache Impala. Poprawny podpis to warunek konieczny, a nie dowód, że cały przepływ jest związany z właściwym kontekstem.

Komunikat Apache mówi, że napastnik nie potrzebuje konta w Airflow ani poświadczeń, a ofiara musi tylko otworzyć przygotowaną stronę. Mechanizm opiera się jednak na „attacker's own assertion”, podpisanej przez IdP skonfigurowanego w Airflow. Moje odczytanie: realistyczny napastnik ma jakąkolwiek tożsamość w tym samym Identity Center (pracownik, kontraktor, przejęte konto o niskich uprawnieniach), która pozwala uzyskać asercję dla aplikacji Airflow. Komunikat tego nie precyzuje, więc traktuj to jako hipotezę, nie ustalenie.

Dlaczego login CSRF w Airflow to nie „tylko moderate”

Login CSRF ma zwykle niskie oceny, bo nie daje dostępu do konta ofiary. Kontekst Airflow zmienia jednak skutki. W bliźniaczym CVE-2026-40948 dla providera Keycloak Apache napisało wprost, że poświadczenia, które ofiara zapisze potem w Airflow Connections, „would be harvestable by the attacker”. Inżynier danych, który myśli, że pracuje na swoim koncie, wkleja hasło do bazy, klucz do hurtowni albo token API do konta napastnika. Komunikat dla CVE-2026-86467 mówi ogólniej: „Subsequent work the victim performs lands in a session the attacker controls”.

To nie jest jedna podatność z dwoma numerami. To dwa pakiety, dwa protokoły i dwie osobne aktualizacje. Kto po kwietniowym CVE zaktualizował providera Keycloak, nie ma przez to załatanego providera Amazon. Z drugiej strony powtórzenie tej samej klasy błędu w drugim auth managerze to sygnał, że warto przejrzeć także własne lub mniej popularne integracje logowania w Airflow. O tym, że poprawki logowania w Airflow bywają niekompletne, pisałem przy CVE-2026-59243.

Koszt poprawki: kafelek w portalu przestaje działać

Poprawka przypisuje każdemu logowaniu nonce, który wędruje do IdP w RelayState, a lista oczekujących logowań trafia do krótkotrwałego, podpisanego ciasteczka (HttpOnly, 10 minut, jedno użycie). Odpowiedź musi pasować do jednego z tych wpisów, a InResponseTo do jego identyfikatora żądania. Konsekwencja, opisana w dokumentacji providera: odpowiedź SAML, która nie zaczęła się od /login w tej przeglądarce, jest odrzucana. Dotyczy to także logowania kliknięciem kafelka Airflow w portalu AWS IAM Identity Center, bo to przepływ IdP-initiated, w którym nikt o asercję nie prosił.

Dla tego scenariusza provider dodał opcję [aws_auth_manager] allow_idp_initiated_login, domyślnie False. Dokumentacja opisuje uczciwie, co się traci po jej włączeniu: Airflow nadal wymaga podpisu skonfigurowanego IdP i odrzuca odpowiedzi z InResponseTo, ale „what it gives up is the guarantee that the browser receiving the response is the one that asked for it”, i zaleca: „Leave it disabled unless the access portal flow is required”. Nie twierdzę, że po włączeniu opcji atak z CVE wraca w identycznej postaci. Twierdzę, że znika ta gwarancja, którą poprawka wprowadziła.

Drugi koszt dotyczy wdrożeń z TLS kończonym na load balancerze. Ciasteczko musi być SameSite=None i Secure, bo odpowiedź z Identity Center przychodzi z innej domeny. Airflow ustawia je tak tylko wtedy, gdy API server widzi żądanie jako HTTPS. Bez airflow api-server --proxy-headers i FORWARDED_ALLOW_IPS każde logowanie kończy się błędem „No login in progress for this browser”.

Dla VE to ważniejsze niż sam numer wersji. Scenariusz jest łatwy do przewidzenia: aktualizacja, zgłoszenia „nie mogę się zalogować z portalu”, ktoś z zespołu platformy znajduje w dokumentacji jedną zmienną środowiskową i ją włącza. Ticket podatności jest zamknięty, bo wersja się zgadza, a część poprawki właśnie wyłączono. To ten sam wzorzec co przy obejściach, które zespoły włączają, żeby przywrócić działanie po poprawce: zmiana konfiguracji z konsekwencjami dla bezpieczeństwa, która nie trafia do żadnego rejestru.

Changelog nie mówi „security”

W changelogu providera dla 9.38.0 poprawka jest w sekcji „Features” jako „Bind the AWS auth manager SAML response to the browser that started the login (#73698, #74529)”, obok nowych operatorów EMR i DuckDB. Nie ma przy niej numeru CVE ani słowa „security”. Kto przegląda changelog w poszukiwaniu poprawek bezpieczeństwa, łatwo ją przeoczy. Na początku tego samego wpisu jest za to ostrzeżenie o zmianie w S3DagBundle (ukośnik na końcu prefiksu, które może wymagać zmiany polityk IAM). To kolejny powód, dla którego aktualizacja providera to zmiana do przetestowania, a nie „bump wersji”.

Ciekawostka z PR, ważna dla oceny jakości: klasa testów TestLoginRouter „was never collected — by anyone, including CI”, bo dekorator kontekstowy zamieniał klasę w funkcję i pytest nic nie znajdował. Po naprawie w pliku jest 27 testów, a dwie asercje, które nigdy wcześniej się nie wykonały, okazały się błędne. Jak długo testy logowania AWS auth managera nie były uruchamiane, PR nie podaje. Dla oceny ryzyka ważne jest to, że zielony CI nie był dowodem, że ta ścieżka logowania jest testowana.

Kogo to dotyczy: najpierw konfiguracja

Pakiet Amazon jest instalowany w ogromnej liczbie wdrożeń Airflow, bo zawiera operatory S3, EMR, Glue czy Redshift. Skaner SCA zgłosi CVE-2026-86467 wszędzie tam, gdzie wersja jest niższa niż 9.38.0. W zakresie są jednak tylko instancje, które używają AWS auth managera z SAML do logowania użytkowników.

Pozostałe instancje to kandydaci do oświadczenia VEX ze statusem not_affected i uzasadnieniem w rodzaju „podatny kod nie jest używany” (komponent obecny, ale auth manager inny). Aktualizację providera i tak warto zaplanować w normalnym cyklu, ale bez SLA dla podatności. Czy dotyczy to także zarządzanego Amazon MWAA, ze źródeł nie wynika. MWAA ma własny model logowania, a komunikat Apache go nie wymienia: niepotwierdzone.

Co powinien zrobić VE

1. Zawęź zakres: z listy instancji z providerem Amazon < 9.38.0 wybierz te, w których auth_manager wskazuje AWS auth manager i skonfigurowano SAML. Resztę obsłuż przez VEX not_affected z zapisanym dowodem (wartość opcji z działającej instancji, nie z repozytorium).
2. W zakresie: aktualizacja do 9.38.0 w obrazie, z którego startuje API server. Wersja rdzenia Airflow nie ma tu znaczenia. Przed wdrożeniem sprawdź konfigurację proxy (--proxy-headers, FORWARDED_ALLOW_IPS) i ostrzeżenie o S3DagBundle.
3. Uprzedź użytkowników, że logowanie z portalu Identity Center przestanie działać i że należy wchodzić przez adres Airflow. To tańsze niż wyjątek.
4. Jeśli biznes wymaga kafelka w portalu: włączenie allow_idp_initiated_login zapisz jako formalny wyjątek z właścicielem, uzasadnieniem i terminem przeglądu. Finding zamknij jako „naprawiony z odstępstwem”, a nie „naprawiony”.
5. Monitoruj dryf: dodaj AIRFLOW__AWS_AUTH_MANAGER__ALLOW_IDP_INITIATED_LOGIN do kontroli konfiguracji (policy as code, przegląd Helm values), żeby flaga nie pojawiła się po cichu przy pierwszym zgłoszeniu do helpdesku.
6. Dla instancji, które były w zakresie: przejrzyj Connections i Variables dodane lub zmienione ostatnio przez konta, których właściciele tego nie potwierdzają. Login CSRF zostawia ślad w postaci logowania na „cudze” konto z adresu ofiary. Czy logi Airflow i Identity Center pozwalają to odtworzyć, zależy od Twojej retencji.
7. Przy okazji: sprawdź, czy provider Keycloak (CVE-2026-40948) jest ≥ 0.7.0 wszędzie, gdzie jest używany. Ta sama klasa błędu w dwóch auth managerach to dobry powód, żeby zrobić przegląd wszystkich integracji logowania w Airflow.

Powiązane na blogu

• Apache Airflow CVE-2026-59243 — patch naprawił podpis JWT, ale zostawił issuer/audience
• Prowler CVE-2026-59151 — podpis SAML poprawny, token w złym tenancie
• Apache Impala — wcześniejsze poprawne etapy SAML nie dowodzą integralności końcowej tożsamości

Źródła

• Apache Airflow — ogłoszenie CVE-2026-86467 na liście users@airflow.apache.org (19.10.2026) — lists.apache.org
• Apache Airflow — PR #73698 „Bind the AWS auth manager SAML response to the browser that started the login” — github.com
• Apache Airflow — dokumentacja providera Amazon: konfiguracja Identity Center, HTTPS za proxy, IdP-initiated SSO — github.com
• Apache Airflow — changelog providera Amazon (9.38.0) — github.com
• PyPI — apache-airflow-providers-amazon 9.38.0 (17.10.2026) — pypi.org
• NVD — CVE-2026-86467 (CNA Apache, CWE-352, bez CVSS) — nvd.nist.gov
• NVD — CVE-2026-40948 (provider Keycloak, CISA ADP CVSS 3.1 5.4, SSVC) — nvd.nist.gov
• CISA Known Exploited Vulnerabilities Catalog (brak obu CVE w wersji 2026.10.21) — cisa.gov
• FIRST — EPSS API (CVE-2026-86467, 22.10.2026) — first.org

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 20 października 2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 17:20–19:15 CEST): ogłoszenie Apache na liście users@airflow.apache.org (treść, data wysyłki 19.10.2026 15:47 UTC, ocena „moderate”, zakres, zgłaszający), rekordy NVD API 2.0 dla CVE-2026-86467 i CVE-2026-40948, strona PR #73698 (opis mechanizmu, poprawki, opcji IdP-initiated i problemu z kolekcją testów), pliki changelog.rst i identity-center.rst providera Amazon na gałęzi głównej, PyPI (daty wydań 9.36.0–9.38.0), katalog CISA KEV w wersji 2026.10.16 (ponownie sprawdzony 22 października 2026 w wersji 2026.10.21: bez zmian dla opisywanych CVE) oraz API FIRST EPSS. Względem szkicu poprawiłem datę: Apache ogłosiło CVE 19 października, a 20 października rekord trafił do NVD. Dodałem też koszt operacyjny poprawki i opcję allow_idp_initiated_login, o których szkic nie wspomina. Nie potwierdziłem: treści uzupełniającego PR #74529, ostatecznej oceny CVSS (żadna nie została opublikowana), czy ktokolwiek wykorzystał błąd, ilu wdrożeń dotyczy konfiguracja AWS auth manager + SAML, czy napastnik potrzebuje tożsamości w tym samym Identity Center (to moje wnioskowanie), czy dotyczy to Amazon MWAA ani czy wszystkie wcześniejsze wersje 9.x zawierają podatny kod (komunikat mówi „before 9.38.0”). Interpretacja skutków w kontekście Connections dla CVE-2026-86467, ocena ryzyka opcji IdP-initiated, propozycja VEX, kryteria wyjątku i lista działań to oceny autora, nie ustalenia Apache.