Executive brief
Apache Airflow's Keycloak authentication provider (version 3.3+) uses signed session tokens to identify users but stores Keycloak access and refresh tokens in separate unsigned cookies without verifying they belong to the same user. An attacker with any valid Airflow login can pair it with a victim's Keycloak token obtained through other means, allowing them to execute actions with the victim's Keycloak permissions while audit logs record the attacker's identity. This vulnerability could enable unauthorized access to protected resources and data manipulation across systems authenticated via Keycloak.
Technical details
The vulnerability is a session token binding failure in Apache Airflow's Keycloak auth manager. The root cause: Keycloak access and refresh tokens moved from inside the signed Airflow session token to separate, unauthenticated cookies in Airflow 3.3+, but the code never validates that these cookies describe the same subject as the signed session token. An attacker holding a valid Airflow session can inject a different user's Keycloak token via cookies; authorization decisions use the foreign token (granting foreign privileges), while session identity and audit logs show the attacker's account. The refresh flow re-issues session tokens carrying the mismatched pairing, persisting across sessions. Attack requires network access to Airflow and possession of another user's Keycloak tokens (obtained out-of-band) plus the attacker's own valid login. The fix (apache-airflow-providers-keycloak 0.10.0+) verifies that cookie-supplied tokens' `sub` claim matches the session identity before use.
Affected products
- Apache Airflow 3.3 and later
- Apache apache-airflow-providers-keycloak before 0.10.0
Timeline
- 2026-09-16: disclosed
- 2026-08-29: patched: Fix merged in apache/airflow PR #72207