CVE-2026-59243 — Apache Airflow FAB provider: the Azure AD OAuth login decoded ID tokens with signature verification off by default, letting anyone log in as Admin

Apache's own disclosure describes a straightforward broken trust boundary in the Flask-AppBuilder auth-manager provider for Airflow: the Azure AD OAuth login path decoded the identity-provider-supplied JWT ID token with verify_signature left at False, which means the login logic read the token's claims without ever checking that Azure AD had signed them (Apache Airflow security team, 2026-07-28). The consequence is that the token's alg header can be set to none — or the signature simply forged — and the deployment will accept whichever username the attacker writes into the claims, up to and including an account holding the Admin role; BSI's republication states the same outcome in its own words, that a remote anonymous attacker can bypass security measures and obtain administrator rights (BSI CERT-Bund, 2026-07-27). This is a shipped default rather than a customer misconfiguration: nothing beyond selecting Azure AD OAuth as the login method is required to be exposed, and Apache notes the equivalent Authentik login path was already defaulting to True (Apache Airflow security team, 2026-07-28). Neither party reports in-the-wild exploitation, and the fix landed essentially alongside the disclosure — Apache's advisory and the remediation both dated 2026-07-27/28.

Why it matters beyond the CVSS-shaped hole in the record: Airflow instances are orchestration control planes that hold connection objects and variables for the systems they schedule against — database credentials, cloud service-account keys, API tokens — and an Admin-role session is enough to read and edit them, or to author a DAG that runs attacker-chosen code on the workers. Detection: the relevant telemetry class is the application's own authentication events plus the reverse proxy or web-server access log in front of the Airflow webserver — look for successful logins through the OAuth callback whose ID token carried an alg of none, or whose signature cannot be validated against the tenant's published JWKS, and for Admin-role sessions originating from the OAuth path rather than from the accounts your identity provider actually grants that role to. Triage: legitimate Azure AD OAuth logins arrive with a token signed by a key published in the tenant's JWKS document and resolve to a user your directory can account for; the discriminator is a token that validates against no published key, or an authenticated session whose named principal does not exist as an assigned Airflow Admin in the identity provider. Hardening: upgrade the provider to 3.7.3; where the version is pinned, set verify_signature=True explicitly, and treat any Admin session created through this login path before the upgrade as suspect — rotating the credentials and connection secrets stored in that Airflow instance is the part an upgrade does not do for you.