The vulnerability arises because the Airflow Keycloak authenticator separates the signed session token from the Keycloak access and refresh tokens, which are instead stored in separate, unauthenticated cookies. When a user logs in, Airflow takes the session identity from the signed token but uses the tokens from the cookies to make authorization decisions, without verifying that the cookie tokens correspond to the same subject. As a result, an authenticated user who also has a foreign Keycloak access or refresh token can pair their own session with the foreign token. Based on the description, the likely attack vector is manipulating the unauthenticated cookie to supply a foreign Keycloak token, allowing the system to honor the foreign privileges while the audit logs and session name continue to reference the attacker’s account.

The flaw impacts any Airflow deployment using version 3.3 or newer with the apache-airflow‑providers‑keycloak package configured to use the Keycloak authentication manager. All users of this provider that rely on cookie‑supplied Keycloak tokens are affected. Deployments running Airflow before 3.3 embed the Keycloak tokens inside the signed session token, so these earlier releases are not impacted by this issue.

Although the EPSS score is less than 1%, the vulnerability enables a straightforward privilege escalation that does not require special network or privilege exploits. The attacker only needs a valid Airflow login for themselves and an additional Keycloak token for another user, which can be obtained through token leakage or social engineering. The lack of token binding means that the mismatch survives session refreshes, effectively allowing the attacker to perform actions with the foreign user’s permissions while remaining logged in as themselves. The vulnerability is not listed in CISA KEV, but its impact on confidentiality, integrity and availability could be substantial, especially in multi‑tenant environments that rely on Keycloak for role‑based access control.