CVE-2026-82355 in Airflow
Summary
by MITRE • 09/21/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability in question represents a critical authentication precedence flaw within specific versions of the Apache Airflow core API, specifically affecting releases 3.3.0 and 3.3.1. This issue stems from an incorrect implementation of how the application resolves user identity when multiple forms of credentials are presented simultaneously during a single HTTP request. In standard security architectures, explicit authentication tokens such as Bearer tokens typically hold higher precedence than session cookies because they represent direct, intentional credential submission by the client rather than stateful browser-based sessions which may be subject to various side-channel attacks or legacy behaviors. However, in this vulnerable configuration, when an incoming API request contains both a valid session cookie and an explicit Authorization header with a Bearer token, the Airflow application incorrectly prioritizes the identity derived from the session cookie while completely ignoring the explicitly provided bearer token. This inversion of intended precedence creates a significant discrepancy between the authenticated user as perceived by the system and the actual credentials presented by the client software initiating the request.
The operational impact of this flaw is primarily centered on principal confusion and the integrity of audit logging rather than direct privilege escalation or unauthorized access to restricted resources in isolation. Because the application executes the requested action using the identity associated with the session cookie, any actions performed are attributed to that user in the system's audit logs. This misattribution can severely compromise forensic analysis capabilities, making it difficult for security teams to accurately trace malicious activities back to their true source if an attacker manages to manipulate this condition. Furthermore, while the vulnerability itself does not allow a low-privileged user to directly escalate privileges within Airflow by exploiting this specific code path, it facilitates identity spoofing scenarios where actions taken under one identity are recorded as being performed by another. This undermines trust in audit trails which are essential for compliance and security monitoring in enterprise data engineering environments.
Exploitation of this vulnerability requires a pre-condition that an attacker must successfully inject or manipulate the session cookie within the victim's client environment before sending requests to the Airflow API. Common vectors for achieving this include cross-site scripting attacks on other applications hosted on the same parent domain, which allows script injection to set cookies accessible by the Airflow subdomain. It also includes scenarios involving sibling subdomains where one compromised application can write cookies readable by another due to shared domain suffixes, a technique often referred to as cookie tossing or HTTP header manipulation via cross-domain requests depending on specific browser security policies and CORS configurations. Additionally, physical access attacks such as those conducted from a shared workstation where an attacker has control over the victim's browser session could also facilitate this condition. Deployments that host the Airflow user interface on domains shared with other web applications are at significantly higher risk compared to isolated deployments running on dedicated, exclusive domains without co-hosted services.
From a classification perspective, this vulnerability aligns closely with CWE-287 Improper Authentication and CWE-613 Insufficient Session Expiration as it involves the mismanagement of authentication mechanisms leading to identity confusion. In terms of MITRE ATT&CK framework mapping, this behavior relates to techniques involving credential manipulation or abuse of trust relationships between services, specifically falling under categories that describe how attackers can bypass intended security controls by exploiting ambiguities in authentication logic. The lack of proper precedence handling for different credential types is a common pattern in complex web applications where multiple authentication backends are integrated without clear priority rules defined during the request processing lifecycle.
To mitigate this risk and restore correct authentication behavior, organizations running Apache Airflow versions 3.3.0 or 3.3.1 must upgrade immediately to version 3.3.2 or any later release. The patched versions resolve the caller identity resolution logic by ensuring that when an explicit Authorization header with a Bearer token is present in the request, it takes precedence over any session cookies provided in the same request. This ensures that the audit logs accurately reflect the principal explicitly authenticated by the client application rather than potentially stale or manipulated session data. For deployments unable to upgrade immediately due to operational constraints, implementing strict domain isolation for Airflow services and ensuring no other applications share the same cookie scope can reduce the attack surface available for pre-condition exploitation via cross-domain attacks.