Apache Software Foundation's Apache Airflow bearer-token logout flaw leaves sessions valid

Apache Airflow: the Core API logout endpoint revokes only a session token presented as the _token cookie. When a client logs out presenting its credential as an Authorization bearer header instead, the endpoint returns its normal logout response but revokes nothing, so the token remains valid until it expires. An attacker who already holds a copy of that token keeps the victim's access after the victim has logged out and believes the session ended; the default token lifetime is 24 hours and is configurable. Affects API clients that authenticate with a bearer token rather than the browser session cookie. The attacker must already possess a copy of a valid token; obtaining one is outside the scope of this issue, and no privileges beyond the victim's own are gained. Users of apache-airflow are recommended to upgrade to apache-airflow version 3.3.2 or later, which fixes the issue.

• The apache-airflow package from Apache Software Foundation is affected from version 3.0.0 and less than version 3.3.2 under semver.
• The normalized record marks the default status as unaffected outside the listed range, but it does not provide separate boundaries for parallel or other branches. Do not infer the status of branches that are not explicitly listed.
• Apache states that the issue is fixed in version 3.3.2.

The Core API logout endpoint revokes only a session token presented in the _token cookie. When a client presents its credential in an Authorization: Bearer header instead of the browser session cookie, the endpoint still returns its normal logout response but does not revoke the bearer token. That token remains valid until it expires; the default lifetime is 24 hours and is configurable. The upstream fix described in the public pull request changes the flow to collect every credential presented in the request with collect_request_tokens() and revoke them before any redirect or cookie deletion. The public evidence does not establish how an attacker obtained a copied token; token acquisition is outside the scope of this issue.

The vulnerable behavior is remotely reachable through the Core API logout endpoint. The attacker must already possess a copy of a valid bearer token belonging to the victim; obtaining that token is outside the scope of the issue. After the victim logs out, the attacker can continue using the token until it expires, within the permissions already represented by that token. The advisory does not describe an additional victim interaction requirement and states that the attacker gains no privileges beyond the victim's own. The reviewed evidence does not identify a named campaign, victim, or public exploit.

The technical outcome is that logout does not terminate the bearer token supplied in the Authorization header. A copied token can continue authenticating API requests after its owner logs out, with no greater privilege than the token originally carried. This could cause confidentiality or integrity impact within the token's permitted scope, but it does not grant the attacker additional privileges. The issue is not described as an availability failure, and the evidence does not provide a specific token-acquisition vector.

API users may believe that logout ended a session when the associated bearer token is still active. Anyone who already holds a copy of that token may continue performing API operations within the victim's permissions, which could allow access to or modification of resources available to that token. Exposure can continue until the token expires, with a default lifetime of 24 hours and a configurable duration. This is a session invalidation failure; obtaining the token is not part of the described issue.

1. Upgrade apache-airflow to version 3.3.2 or later, as recommended by Apache. The recorded affected range is 3.0.0 through versions before 3.3.2.
2. After upgrading, verify that every deployment, worker, or service using the Core API runs the fixed build; checking browser-cookie behavior alone is insufficient because the issue concerns bearer-token clients.
3. During rollout, treat bearer tokens used to log out as potentially valid until expiry. The public source does not specify a separate emergency procedure for revoking them beyond the organization's existing credential-management mechanisms.

1. Inventory apache-airflow installations and compare them with the affected release boundary.
2. Identify API clients that send credentials in an Authorization: Bearer header rather than the _token cookie; these clients are directly exposed to the described behavior.
3. In a controlled test environment, log out with a bearer token and verify that a subsequent request using that token is rejected. Do not treat a normal logout response as proof that the token was revoked.
4. Review API gateway and Airflow logs for continued use of a bearer token after the associated logout event. This is precautionary monitoring, not a vendor-confirmed indicator.
5. For affected deployments, treat tokens used during logout as potentially valid until expiry; absence of subsequent log use does not prove that a token was safely revoked.