CVE-2026-75156 in Airflow FAB Providerinfo

Summary

by MITRE • 09/08/2026

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.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 09/08/2026

The Apache Airflow FAB provider versions ranging from 3.7.3 through 3.8.0 contain a critical authentication bypass vulnerability that allows unauthorized access to the Airflow web interface when configured with Azure Active Directory as an OAuth identity provider. This flaw stems from a failure in the OpenID Connect validation process, specifically regarding the verification of standard JWT claims such as issuer and audience. While previous remediation efforts addressed signature integrity by ensuring tokens were signed correctly using keys fetched from Microsoft's multi-tenant JSON Web Key Set endpoint, they neglected to enforce strict identity assertions. Consequently, any validly signed Azure AD id_token is accepted regardless of its origin or intended recipient, creating a severe security gap that undermines the fundamental trust model of federated authentication systems.

From a technical perspective, the vulnerability exploits the behavior of Microsoft's multi-tenant JWKS endpoint which serves public keys for all Azure tenants rather than restricting them to specific organizational boundaries. Because the application validates the cryptographic signature against these universal keys without checking whether the token was issued by an authorized tenant or intended for this specific Airflow deployment, it becomes possible for any external entity to forge a valid login session. An attacker who registers their own Azure AD tenant can generate id_tokens that pass all existing validation checks performed by the vulnerable software versions. The application then extracts the username and role assignments directly from these attacker-controlled tokens, effectively granting the adversary administrative privileges or access to sensitive data without possessing any legitimate credentials for the target organization.

The operational impact of this vulnerability is severe, as it enables complete authentication bypass for deployments relying on Azure AD integration. Since no prior access to the internal network or existing Airflow accounts is required, an attacker can initiate a login flow from anywhere on the internet and gain immediate entry into the system. This compromises the confidentiality, integrity, and availability of all resources managed by Apache Airflow, including data pipelines, scheduled tasks, and sensitive configuration files. The risk is particularly acute in environments where Azure AD is used as the primary identity source for multiple applications or services, as a single compromised tenant can lead to widespread unauthorized access across integrated systems that share similar trust configurations.

This issue aligns with CWE-287 Improper Authentication because the system fails to properly verify the identity of the user during the authentication process by neglecting critical claim validation. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as attackers can leverage legitimate-looking but maliciously crafted tokens to impersonate authorized users and gain access to computer systems without exploiting software vulnerabilities in the traditional sense. The flaw represents a classic case of incomplete mitigation where partial fixes leave residual risks that are often overlooked by operators who assume their security posture is hardened after applying initial patches.

To mitigate this risk, organizations must upgrade apache-airflow-providers-fab to version 3.8.1 or later immediately. It is crucial to note that deployments which previously applied the fix for CVE-2026-59243 remain vulnerable because those earlier updates only addressed signature verification and omitted issuer and audience checks. Therefore, upgrading from any affected version within the 3.7.3 through 3.8.0 range is mandatory even if recent security patches have been installed. Administrators should also review their Azure AD application configurations to ensure that appropriate restrictions are in place at the identity provider level, such as restricting token issuance to specific tenants or enforcing audience validation policies on the Microsoft side where possible, although software-level fixes remain the primary defense against this specific implementation flaw.

Responsible

Apache

Reservation

08/17/2026

Disclosure

09/08/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!