Airflow Keycloak provider: Keycloak tokens from unsigned cookies are not bound to the session identity

Impact

From Airflow 3.3 the Keycloak auth manager reads the user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate unsigned cookies, without checking that both describe the same subject. A user with any valid Airflow login who obtains another subject's Keycloak access or refresh token out of band can pair the two: Airflow authorizes with the foreign token's privileges while the session identity, audit log and cache keys still name the attacker's own account. That is privilege escalation over pipeline and job control with misleading audit trails - the operator investigating later sees the wrong user. The refresh path re-issues the session token carrying the foreign tokens, so the mismatch persists across sessions. Distinct from CVE-2026-76187 in the same release: different mechanism, and this one needs an existing Airflow login.

Who can reach it

An authenticated Airflow user - any legitimate low-privilege account - who has separately obtained a victim's Keycloak access or refresh token. Applies to deployments on Airflow 3.3 or later using the Keycloak auth manager.

What to do

Upgrade apache-airflow-providers-keycloak to 0.10.0 or later, which binds the cookie-supplied tokens to the session identity. Provider package upgrade plus a restart of the API server / webserver; no node drain. Airflow versions before 3.3 carried the Keycloak tokens inside the signed session token and are not affected.

References

Related entries

• Fortra BoKS Manager: command injection in crlserver gives root on the BoKS Master via a crafted CRL URLCVE-2026-79898 · Fortra BoKS Manager crlserver (CRL URL handling)Critical
• Airflow FAB provider: password change through the Admin PATCH endpoint does not evict existing sessionsCVE-2026-86462 · Apache Airflow FAB provider (Admin user-edit PATCH endpoint, session invalidation)Critical
• Apache Airflow: Core API logout does not revoke bearer tokens, so a stolen token outlives the sessionCVE-2026-86473 · Apache Airflow Core API (logout endpoint, bearer-token revocation)Critical
• Apache Airflow SSH/SFTP providers: host-key checking off by default, so workers trust any server keyCVE-2026-94134 · Apache Airflow SSH and SFTP provider hooks (host-key verification default)Critical
• AMD EPYC / Ryzen - Hardware Validated Boot enforcement: Hardware Validated Boot is not properly enforced, so anCVE-2018-8930 · AMD EPYC / Ryzen - Hardware Validated Boot enforcementCritical
• AMD EPYC Server - protected memory region access control: Insufficient access control over protected memory regions onCVE-2018-8933 · AMD EPYC Server - protected memory region access controlCritical