CVE-2026-76186

In the Apache Airflow Keycloak provider, from Airflow 3.3 the Keycloak auth manager takes the user's identity from the signed Airflow session token but reads the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, without ever verifying that the two describe the same subject (CWE-565). An attacker who holds any valid Airflow login of their own and obtains another subject's Keycloak access or refresh token out of band can pair the two, so Airflow authorizes requests with the foreign token's privileges while the session identity, audit log and cache keys continue to name the attacker's own account. The refresh path re-issues an Airflow session token for the attacker's identity carrying the foreign tokens, so the mismatched pairing survives across sessions. Affected deployments are those running Airflow 3.3 or later with the Keycloak auth manager (apache-airflow-providers-keycloak before 0.10.0); earlier versions kept the Keycloak tokens inside the signed session token, preserving the binding. No public proof-of-concept, KEV listing, or reported in-the-wild exploitation is known, and a CVSS score has not yet been assigned.

What to do: Upgrade apache-airflow-providers-keycloak to version 0.10.0 or later, which binds the cookie-supplied Keycloak tokens to the session identity. Until patched, restrict how Keycloak tokens are issued and shared, and review audit logs for accounts performing actions beyond their expected privileges. Confirm whether your deployment runs Airflow 3.3 or later with the Keycloak auth manager, as other auth managers and pre-3.3 versions are not affected.