GPU VulnDB

Database/Control plane, storage & DevOps

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

CVSS 9.1CVE-2026-76186Control plane, storage & DevOpscurated

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

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.