CVE-2026-82355: Apache Airflow: Session cookie silently overrides explicit Authorization bearer header, enabling session fixation
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Airflowto a version that resolves this vulnerability.Fixed in 3.3.2
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Only Apache Airflow 3.3.0 and 3.3.1 are affected. Deployments whose Airflow UI shares a parent domain with other applications are most exposed, while a dedicated domain with no co-hosted applications is not reachable through the described cookie-placement paths.
What must an attacker do before they can exploit the behavior?
The attacker must first cause a valid session cookie belonging to the attacker to be placed in the victim's browser or client. Described methods include cookie tossing from a sibling subdomain, cross-site scripting in another application sharing the parent domain, or access to a shared workstation.
Does this allow the attacker to gain the victim's privileges?
The described impact is principal confusion and audit-log misattribution, not direct privilege escalation. Requests carrying both credentials execute as the session-cookie principal rather than the identity represented by the explicit bearer token.