Apache Airflow CVE-2026-82355

Requires Apache Airflow 3.3.0 or 3.3.1 specifically - earlier and later releases lack the cookie-caching code path and are not vulnerable. The attacker must first place a valid _token session cookie of their own into the victim's browser or client (via cookie-tossing from a sibling subdomain, XSS in a separate application sharing the parent domain, or a shared workstation), AND the victim's request must simultaneously carry an explicit Authorization: Bearer or OAuth2 credential. LIMITING FACTORS: only deployments hosting the Airflow UI on a domain shared with other applications are exposed - an Airflow instance on a dedicated domain with no co-hosted applications is not reachable this way; the attacker must already possess a valid Airflow session (authenticated); and the outcome is misattribution/audit corruption, not access to resources the attacker couldn't otherwise reach.

No CVSS score or vector was supplied in any input source, so severity signals must be reasoned from the description and patch. There is no EPSS score, no CISA KEV listing, and no public POC - so this is 'no public exploit identified at time of analysis.' The vulnerability is a credential-precedence inversion (CWE-384): on Apache Airflow 3.3.0/3.3.1 core-API routes, JWTRefreshMiddleware caches a user resolved from the _token session cookie onto request.state, and get_user() returns that cached principal before it ever inspects an explicit Authorization: Bearer or OAuth2 credential, so the cookie silently overrides the bearer token. Critically, the vendor description explicitly states the consequence is 'principal confusion and misattributed audit records rather than a direct privilege escalation' - the request executes as the cookie's identity, not as an elevated identity the attacker didn't already hold. This is a real integrity/attribution defect but a LOW real-world priority: exploitation is heavily gated (attacker must first plant their own valid session cookie in the victim's client, and only deployments sharing a parent domain with other apps are reachable), the affected version window is just two point releases, and there is no confidentiality or availability impact. The 'Privilege Escalation' tag OVERSTATES the actual impact and directly contradicts the vendor's own text; treat this as an auditing/attribution integrity issue, not an escalation primitive.

An attacker who holds their own low-privilege Airflow account first injects their _token session cookie into a victim's browser or client - e.g. cookie-tossing from a sibling subdomain, exploiting XSS in a different application co-hosted on the shared parent domain, or using a shared workstation. When the victim's client then calls the Airflow core API presenting its own Authorization: Bearer token alongside the planted cookie, Airflow 3.3.0/3.3.1 resolves and audit-logs the action as the attacker's cookie principal instead of the bearer identity the client actually presented. No public exploit code is identified at time of analysis.