CVE-2026-75156
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk8th percentile - higher than 8% of all known CVEs
Summary
Apache Airflow FAB provider versions 3.7.3 through 3.8.0 do not validate the issuer or audience of Azure AD `id_token`s during OAuth login. Deployments are affected only when the FAB auth manager is configured with Azure AD as an OAuth provider. Because the signing keys are fetched from Microsoft's multi-tenant JWKS endpoint, an `id_token` minted in any Azure tenant — including one the attacker creates — passes signature verification, and the username and role assignments are then read from that attacker-controlled token. Anyone able to register an Azure tenant can therefore authenticate to the Airflow UI with no prior access to the deployment.
Risk Assessment
The risk includes unauthorized access to the Airflow UI, which may lead to control over workflows, data modification, and potential execution of malicious code in the Airflow environment.
Recommendation
Immediately upgrade apache-airflow-providers-fab to version 3.8.1 or later. Even if the CVE-2026-59243 fix was previously applied, an upgrade is required again because that version remains vulnerable.
Other vulnerabilities in Apache Airflow FAB provider
See all- CVE-2026-86462Critical
In the Apache Airflow FAB provider, changing a user's password via the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker holding a copy of the victim's session cookie retains full access after the password change.
- CVE-2026-82311Critical
In the Apache Airflow FAB provider, resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour. The cleanup compares a string session identifier with the user's integer database identifier, so the comparison never matches and no session is removed, leaving an attacker with a copied cookie still authenticated.
- CVE-2026-86466High
Apache Airflow FAB provider: the Authentik OAuth path in the FAB auth manager does not validate the issuer or audience claims of the id_token it accepts. An attacker holding a token that the same Authentik identity provider minted for a different client application can present it to Airflow and be authenticated as the user it names, because the audience claim is never checked. Affects deployments using the FAB auth manager with Authentik OAuth where the same Authentik instance also serves other applications.
- CVE-2026-82310High
In Apache Airflow FAB provider, deactivating a user account does not invalidate previously issued tokens. These tokens remain valid and can be used to gain access even after the account is deactivated by an administrator.
Original NVD description (English source)
Apache Airflow FAB provider versions 3.7.3 through 3.8.0 do not validate the issuer or audience of Azure AD `id_token`s during OAuth login. Deployments are affected only when the FAB auth manager is configured with Azure AD as an OAuth provider. Because the signing keys are fetched from Microsoft's **multi-tenant** JWKS endpoint, an `id_token` minted in *any* Azure tenant — including one the attacker creates — passes signature verification, and the username and role assignments are then read from that attacker-controlled token. Anyone able to register an Azure tenant can therefore authenticate to the Airflow UI with no prior access to the deployment. The fix for **CVE-2026-59243** was incomplete, and this advisory closes the remaining gap: that fix made the provider verify the `id_token` signature, but did not add issuer or audience checks. Operators who already applied the CVE-2026-59243 fix are **still affected and must upgrade again** — 3.7.3 is the release that shipped that fix, so every version containing it falls inside this affected range. Upgrade to apache-airflow-providers-fab `3.8.1` or later.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS