Apache Airflow CVE-2026-75156

Exploitable only when the Airflow FAB auth manager is configured with Azure AD as an OAuth provider (the vulnerable id_token validation path). Given that configuration, no further conditions apply: a remote, unauthenticated attacker needs only the ability to register their own Azure AD tenant (freely available) and craft an id_token with attacker-chosen username and role claims, which passes because issuer and audience are unchecked against Microsoft's multi-tenant JWKS. Limiting factors: deployments not using Azure AD OAuth via the FAB provider are unaffected, and versions outside 3.7.3-3.8.0 are not vulnerable; there is no user-interaction or pre-existing-account requirement on the target side.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, 9.1) is well-supported by the mechanism: a remote, unauthenticated attacker who can self-register a free Azure tenant obtains a valid-looking login with attacker-chosen username and role assignments, yielding high confidentiality and integrity impact over Airflow (DAG code, connections/secrets, and pipeline execution) with no availability impact claimed. The one genuine gating factor is configuration: only deployments using the FAB auth manager with Azure AD as an OAuth provider are affected, so the raw 9.1 overstates population-wide risk while accurately reflecting risk for the affected configuration. No EPSS score, CISA KEV entry, or SSVC decision data was provided, and no public exploit was identified at time of analysis; however, exploitation requires no privileged setup beyond registering an Azure tenant, so any organization running this configuration should treat it as urgent and patch immediately. Notably, the incomplete-fix nature is a trap: teams that already patched CVE-2026-59243 (which shipped in 3.7.3) may believe they are safe when in fact every version carrying that fix falls inside this affected range.

An attacker registers a free Azure AD tenant, creates a user in it, and initiates OAuth login to a target Airflow deployment configured with Azure AD, submitting an id_token minted by their own tenant with a chosen username and admin role claims. Because the FAB provider verifies only the Microsoft multi-tenant signature and not the issuer or audience, the token is accepted and the attacker is logged in with administrative access to DAGs, connections, and secrets. No prior access to the deployment is needed and no public exploit tool was identified, though the mechanism is fully described in public advisories.