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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-09-21T15:17:32.430Z",
  "pubdate": "2026-09-21T15:17:32.430Z",
  "executiveSummary": "A principal confusion vulnerability exists in Apache Airflow versions 3.3.0 and 3.3.1 due to improper precedence handling of authentication credentials.\nWhen a request provides both a session cookie and an Authorization: Bearer token, the system erroneously prioritizes the session cookie, ignoring the bearer token.\nThis leads to incorrect identity resolution where requests are executed and audit-logged under the identity associated with the session cookie rather than the caller's explicit bearer token.\nThe vulnerability poses significant risks to audit integrity and non-repudiation.\nExploitation requires an attacker to successfully perform session fixation or cookie tossing, typically via cross-site scripting (XSS) on shared domains, subdomain exploitation, or shared workstation access.\nThe primary impact is the misattribution of actions within the audit log and potential authorization bypass if the attacker's cookie possesses different privileges than the intended bearer token context.\nDeployments utilizing dedicated domains are less susceptible to external exploitation vectors.",
  "technicalDetails": "The root cause of this vulnerability lies in the request authentication middleware of Apache Airflow 3.3.0 and 3.3.1. The implementation fails to enforce a strict precedence hierarchy when multiple authentication mechanisms are present simultaneously.\nSpecifically, the code path responsible for resolving the security principal performs a lookup that caches the user identity derived from the session cookie, effectively locking the request context before evaluating the presence of an Authorization: Bearer header.\nThis inversion of precedence violates the expected security contract where an explicit, cryptographic bearer token should override implicit session-based authentication.\nThe exploitation flow begins with the attacker placing a valid session cookie they control into the victim's environment. This can be achieved through techniques such as cookie tossing from a sibling domain, leveraging a cross-site scripting (XSS) vulnerability in a co-hosted application on a shared parent domain, or direct access via shared hardware.\nOnce the cookie is injected, the attacker triggers an API request from the victim's browser or a client controlled by the attacker that includes both the victim's legitimate bearer token and the attacker-controlled session cookie.\nThe Airflow server processes this request by resolving the identity from the cookie, disregarding the bearer token provided in the Authorization header. Consequently, the API operation is authorized and logged using the principal associated with the attacker-injected cookie.\nThe vulnerable component is the core API request handling logic. Because earlier versions (prior to 3.3.0) do not implement this specific identity caching mechanism, they remain unaffected by this flaw.\nThe post-exploitation impact is primarily characterized by audit log falsification, which obscures the origin of API calls and complicates forensic investigations. Furthermore, it creates a principal confusion state where the system performs actions under an unintended security context, potentially violating the principle of least privilege if the cookie-based user has elevated or different permissions compared to the bearer token owner.\nThis vulnerability is particularly dangerous in multi-tenant or shared-hosting environments where the blast radius of a cookie injection is amplified by the proximity of unrelated applications."
}