AI analysis
In Apache Airflow 3.3.0 and 3.3.1, a request to the core API that carries both a session cookie and an explicit Authorization: Bearer token is resolved from the cookie, inverting the intended bearer-over-cookie precedence. An attacker who can first plant one of their own valid session cookies into the victim's browser or client — for example via cookie tossing from a sibling subdomain, XSS in another application sharing a parent domain, or a shared workstation — causes the request to execute and be audit-logged as the attacker's principal rather than the identity the client explicitly presented. The impact is principal confusion and misattributed audit records, not a direct privilege escalation, and deployments on a dedicated domain with no co-hosted applications are not reachable via this path. No public proof of concept exists, the issue is not in the CISA KEV catalog, and no exploitation has been reported.
What to do: Upgrade Airflow 3.3.0 or 3.3.1 to 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present. As defense in depth, host the Airflow UI on a dedicated domain with no sibling applications on the parent domain, scope session cookies tightly (host-only / __Host- prefixed), and invalidate outstanding sessions during the rollout. Finally, review audit logs from the vulnerable period for API calls recorded under a principal that does not match the bearer-token identity the client presented.
Affected
| Apache Airflow | 3.3.0, 3.3.1 |
Estimated exposure
moderatelikely a few thousand to low tens of thousands of deployments (estimated) — Airflow is among the most widely deployed open-source workflow orchestrators, but only the two newest releases (3.3.0/3.3.1) contain the vulnerable code path and most fleets lag the latest minor version; practical exposure is further…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
When a request to the Airflow core API carries both a session cookie and an explicit `Authorization: Bearer` token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented. Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable. Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation. Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.