--- schema: 1 kind: vulnerability title: "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" headline: "Apache ships airflow-providers-fab 3.7.3 after finding its Azure AD OAuth path accepted unsigned ID tokens as proof of identity" summary: > Apache disclosed CVE-2026-59243 in apache-airflow-providers-fab on 2026-07-27/28: the FAB auth manager's Azure AD OAuth login path decoded the OAuth-supplied ID token with the `verify_signature` parameter defaulted to `False`, so anyone able to reach the OAuth callback and present a forged or unsigned (`alg:none`) token was authenticated as whichever user the token named — including one holding the Admin role. Only deployments using the FAB auth manager with the Azure AD OAuth login path are affected; Apache states the Authentik path already defaulted to `True`. Fixed in apache-airflow-providers-fab 3.7.3, which flips the default. No exploitation is reported, and no CVSS score has been published by any party. discovered_at: "2026-07-29T05:00:00Z" event_date: "2026-07-27" run_id: 2026-07-29T0408Z-intel priority: high immediate_action: null tags: [vulnerabilities, auth-bypass, pre-auth, default-config, identity, cloud, patch-available] regions: [global] sectors: [public-sector, finance, technology] entities: [] techniques: [T1190, T1606] affected_products: ["Apache Airflow FAB provider"] cves: - id: CVE-2026-59243 cvss: null epss: null type: auth-bypass vector: zero-click auth: pre-auth status: [patch-available] affected: "apache-airflow-providers-fab before 3.7.3. BSI's CSAF record carries the range as an open bound (`<3.7.3`) with no lower limit, and Apache's advisory states only \"before 3.7.3\" — neither party names the release that introduced the Azure AD OAuth login path, so no earliest-affected version can be stated. Only deployments running the FAB auth manager configured for the Azure AD OAuth login path are affected." fixed: "3.7.3 — named as the fixed release both in Apache's own advisory text and as a distinct fixed product entry in BSI's CSAF product tree. Apache states 3.7.3 defaults `verify_signature=True`; setting that parameter explicitly on a pinned older release is the interim equivalent." sources: - url: "https://seclists.org/oss-sec/2026/q3/298" publisher: "Apache Airflow security team (Shahar Epstein, oss-sec)" date: "2026-07-28" role: primary - url: "https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-2551" publisher: "BSI CERT-Bund (WID-SEC-2026-2551)" date: "2026-07-27" role: corroborating closed_sources: [] evidence: - quote: "Severity: moderate" publisher: "Apache Airflow security team (Shahar Epstein, oss-sec)" - quote: "MalHyuk (finder)" publisher: "Apache Airflow security team (Shahar Epstein, oss-sec)" verification: multi-source sourcing_note: > Two publishers, but they are not independent assessments of the same facts: BSI CERT-Bund's advisory is a republication of Apache's disclosure, so the technical claims rest on Apache's own account of its own codebase. The two do diverge on one point worth recording — Apache labels the issue "moderate" in its own advisory text while BSI's CSAF carries a document-level aggregate severity of "hoch" (high) for the identical flaw. No CVSS vector or score is published by either party: Apache gives a severity word only, BSI's CSAF has no scores block for this CVE, and a direct query to MITRE's CVE record API on 2026-07-29 returned `CVE_RECORD_DNE` — the identifier is in use in both advisories but has not yet propagated to a published MITRE record. `cvss` is therefore null rather than estimated. Credibility is rated 2 rather than 1 for that same reason: two publishers carry the item, but only one of them assessed it, so the claim is authoritative without being independently corroborated. confidence: high update_of: null references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: A credibility: 2 watchlist_hit: false actions: - "Upgrade apache-airflow-providers-fab to 3.7.3 on every Airflow deployment using the FAB auth manager with Azure AD OAuth, or explicitly set `verify_signature=True` where the provider version is pinned — then review the Airflow user list for unexpected accounts holding the Admin role, since the flaw let a forged token name any user it liked." migrated_from: null --- 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](https://seclists.org/oss-sec/2026/q3/298)). 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](https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-2551)). 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](https://seclists.org/oss-sec/2026/q3/298)). 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.