Apache Software Foundation Apache Airflow session fixation causes principal confusion

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.

• Apache Software Foundation Apache Airflow, package apache-airflow-core: Apache Airflow 3.3.0 and 3.3.1 are affected. The structured affected fact represents the range as 3.3.0 with a less-than boundary of 3.3.2.
• Earlier releases do not contain the cookie-derived user caching path described by the advisory.
• The fix is confirmed in Apache Airflow 3.3.2. The status of every parallel release branch should not be inferred solely from a fix in one branch.
• Exploitability also depends on the deployment context. The described path requires a core API request containing both a session cookie and an explicit credential. A UI hosted on a shared domain is more exposed, while a deployment on a dedicated domain with no co-hosted applications is not reachable through this path.

The flaw is in caller resolution for the Airflow core API in the apache-airflow-core package. JWTRefreshMiddleware resolves a user from the _token cookie alone and places that user on request.state with a trust sentinel. Before the fix, get_user() returned this cached user before checking the bearer or OAuth2 token, so a request carrying both a session cookie and Authorization: Bearer used the cookie principal instead of the explicitly supplied credential.

At a high level, the affected flow is:

1. An attacker places a valid session cookie belonging to the attacker into a victim's browser or client.
2. The client sends a request to the Airflow core API with both that cookie and an explicit credential.
3. Airflow processes the request as the cookie principal and records the audit event under the wrong identity.

The advisory identifies cookie tossing from a sibling subdomain, cross-site scripting in another application sharing a parent domain, and a shared workstation as example ways to place the cookie. Deployments hosting the Airflow UI on a domain shared with other applications are therefore more exposed. The available evidence confirms the precedence error and incorrect audit attribution, but does not establish a direct privilege-escalation path or that every cookie-placement method applies to every deployment.

The core API path is reachable over the network. The supplied record does not require prior attacker privileges, but the attacker must first possess a valid session cookie belonging to the attacker and place it into the victim's browser or client.

• Precondition: the request must carry both a session cookie and an Authorization: Bearer token.
• Complexity: high, because the attacker must first affect the victim client’s cookie state.
• User interaction: required, because the victim browser or client must send a request after the cookie is placed.
• Deployment exposure: an Airflow UI hosted on a domain shared with other applications is more exposed to the described path; a deployment on a dedicated domain with no co-hosted applications is not reachable this way.

The supplied record does not identify a public exploit. Actual exploitation status is not established because the known-exploited field has no conclusion.

The technical outcome is that Airflow can execute a request as the session-cookie principal and record the audit event under that identity even though the client supplied a different bearer credential. This creates principal confusion and makes the audit trail misstate who performed the action.

• The effective authorization context may differ from the credential the client intended to use, but the evidence does not show a direct privilege-escalation mechanism.
• Likely organisational consequences include more difficult incident investigation, reduced audit-trail reliability, and authorization decisions that do not match the client's intended identity.
• The described evidence does not establish impact extending to other systems or causing service disruption.
• Exploitability depends on placing the attacker's valid session cookie into the victim client; a dedicated domain with no co-hosted applications is not reachable through the described path.

The flaw can cause a request to be processed under the session-cookie identity instead of the identity the client deliberately presented with a bearer token.

• Audit records can attribute an action to the wrong principal, reducing the reliability of investigations, reconciliation, and compliance review.
• The request may be evaluated under the cookie principal's authorization context rather than the credential the client intended to use, producing an unexpected allow or deny result.
• Deployments sharing a domain with other applications should receive priority because they expose the cookie-placement conditions described by the advisory.
• The evidence does not confirm direct account takeover, privilege escalation, or service disruption.

1. Upgrade the affected Apache Airflow deployment to 3.3.2, the release identified by the Apache fix as containing the backport for the 3.3.x branch. Verify the installed apache-airflow-core package after deployment.
2. After upgrading, perform a controlled validation that a request carrying both a cookie and an explicit credential resolves the caller from the explicit credential and records the corresponding audit identity. Use non-production identities and data for this validation.
3. If an immediate upgrade is not possible, reduce exposure by reviewing whether the Airflow UI can be isolated from applications sharing the parent domain, and by addressing cookie-placement paths involving sibling subdomains, same-domain applications, or shared workstations. This reduces attack preconditions but is not a confirmed replacement for the fix.
4. The reviewed evidence does not provide a complete configuration workaround. Do not treat domain separation or the absence of anomalous audit records as a substitute for applying the fixed release.

1. Inventory all instances and the installed apache-airflow-core package, recording the exact release before assessing exposure.
2. At a reverse proxy, API gateway, or application telemetry layer, review requests to the Airflow core API that contain both the _token cookie and an Authorization: Bearer header.
3. Compare audit records for mixed-credential requests with the identity of the explicit credential, when the client or gateway records that information. Prioritize records where the principal is the cookie user rather than the identity the client deliberately presented.
4. Review domain topology, sibling subdomains, and applications sharing the parent domain. Assess cookie tossing, cross-site scripting in a same-domain application, and shared-workstation use as exposure conditions, not as confirmed indicators of compromise.
5. The absence of anomalous audit records does not prove that a deployment is safe; combine telemetry results with the actual package version and domain configuration.