Airflow FAB Provider EUVD-2026-80327

Requires a deployment using the FAB auth manager with Authentik OAuth configured, AND the same Authentik instance must also serve at least one other application. The attacker must already hold a valid id_token that Authentik minted for one of those other client applications (not for Airflow). Limiting factors: the audience-only bypass depends on Authentik signing all applications with one shared key set; deployments where Authentik serves Airflow exclusively, or that do not use the FAB Authentik path, are not exposed. Applying the earlier CVE-2026-75156 (Azure AD) fix does NOT protect the Authentik path - upgrade to apache-airflow-providers-fab 3.9.0 is required.

This is a genuine authentication-bypass flaw but a strongly gated one, not a broad remote-takeover. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, 8.1 High) captures the impact - a network attacker with low privileges can impersonate another user, yielding high confidentiality and integrity loss with no availability impact. However, AC:L understates the real preconditions: exploitation requires that the same Authentik identity provider also serve OTHER applications AND that the attacker already hold a valid id_token one of those apps minted - I assess AC:H is more honest. All exploitation signals point to low near-term urgency: EPSS is 0.14% (4th percentile), the CVE is NOT in CISA KEV, and no public exploit code is identified. Patch is confirmed available (apache-airflow-providers-fab 3.9.0, PR #72645 with regression tests). The 'no public exploit identified' status combined with very low EPSS suggests this is a patch-on-schedule item rather than an emergency, despite the High CVSS. Note the Azure AD variant of the same bug (CVE-2026-75156) was fixed earlier in the same file; deployments that patched that one but use Authentik remain exposed until 3.9.0.

An organization runs Airflow with the FAB auth manager and Authentik OAuth, where the same Authentik instance also fronts an unrelated internal app. An attacker who is a legitimate user of that other app obtains the id_token Authentik issued for it, then presents that token to Airflow's Authentik login endpoint; because the audience (and issuer) claim is never checked, Airflow accepts it and logs the attacker in as the user the token names. No public exploit code exists at time of analysis, and the attacker must already possess a valid token for a sibling application.