Apache Airflow: patch CVE-2026-59243 naprawił podpis JWT, ale zostawił issuer/audience — attacker z własnym tenantem Azure nadal loguje się do Airflow

CVE-2026-75156 to świetny przykład różnicy między patch management a Vulnerability Engineering. Apache ujawnił 8 września 2026, że Airflow FAB provider 3.7.3–3.8.0 nadal pozwala na cross-tenant authentication bypass przy Azure AD OAuth — i że jest to incomplete fix wcześniejszego CVE-2026-59243. Poprzednia poprawka dodała weryfikację podpisu id_token. To odpowiada tylko na pytanie „czy token podpisał zaufany klucz Microsoftu?”, nie na „dla jakiego issuera/audience?”.

CVE-2026-75156: implementacja używa multi-tenant JWKS Microsoftu, więc token z dowolnego tenanta Azure (także atakującego) przechodzi walidację podpisu; issuer/audience niesprawdzane → Airflow czyta z tokenu username i role.

Fix: apache-airflow-providers-fab ≥ 3.8.1.

attacker tworzy własny Azure tenant → poprawnie podpisany id_token → Airflow sprawdza signature (OK) → issuer/audience niesprawdzane → attacker-controlled identity/role claims → logowanie bez wcześniejszego dostępu

valid signature ≠ valid identity for this relying party.

Dlaczego to incomplete fix

Apache pisze wprost, że fix CVE-2026-59243 był niepełny. Release 3.7.3 zawierał poprzednią poprawkę, ale właśnie ta wersja otwiera zakres nowego CVE. Organizacja, która zamknęła stary ticket po 3.7.3, ma historycznie poprawny deployment, ale nie dowód, że root security property została osiągnięta. To dobry trigger: new CVE marked incomplete-fix-of old CVE → reopen / reassess linked exceptions (stary wyjątek oparty na „signature validation naprawiona” właśnie stracił ważność).

Weryfikacja to security property, nie wersja

Testy po poprawce: token z właściwego tenanta + audience → accepted; z innego tenanta → rejected; z właściwego tenanta, innym audience → rejected; ze zmienionym payloadem → rejected; brak tokenu → rejected. Affectedness jest configuration-aware — exploitable tylko przy FAB auth manager + Azure AD OAuth + affected version; VEX rozróżnia Azure AD OAuth configured: no → not affected by reachable path od configured: yes, 3.8.0 → affected.

Severity vs blast radius

Apache klasyfikuje Moderate, ale lokalny risk bywa wyższy, gdy Airflow ma szerokie role administracyjne, przechowuje cloud credentials, zarządza produkcyjnymi DAG-ami i pozwala modyfikować kod wykonywany na workerach — wtedy auth bypass do UI daje znacznie większy blast radius niż base severity.

Wniosek

CVE-2026-75156 pokazuje, że authentication nie jest pojedynczym checkiem. Poprawny pipeline sprawdza spójnie signature + issuer + audience + expiry + nonce/state + claims semantics. Naprawienie jednego pola nie gwarantuje naprawienia boundary — patch może być poprawnie wdrożony i nadal nie przywracać właściwości bezpieczeństwa.

Powiązane na blogu

Wazuh: incomplete fix — „patched” ≠ „fixed”
Impala: integralność finalnej tożsamości — najsłabszy etap identity

Źródła

Apache Airflow / oss-security (08.09.2026) — seclists.org
Apache Airflow — PR #71735 — github.com/apache/airflow

Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-75156 (Airflow FAB provider 3.7.3–3.8.0, fix 3.8.1) to incomplete fix CVE-2026-59243: podpis id_token jest sprawdzany, ale issuer/audience nie, co przy multi-tenant JWKS daje cross-tenant bypass. Artykuł koncentruje się na spójnej walidacji tokenu i reopen powiązanych wyjątków.