Apache Airflow Keycloak CVE-2026-76186

Requires all of: (1) a deployment running Airflow 3.3 or later with the Keycloak auth manager enabled (earlier versions embedded the Keycloak tokens in the signed session token and are not affected); (2) the attacker possessing their own valid Airflow session token; and (3) the attacker obtaining another subject's Keycloak access or refresh token out of band (e.g. cookie theft, MITM/proxy capture, or a shared/leaked token). Limiting factors: the foreign Keycloak token is presented to Keycloak, so a fully forged token is rejected - a genuine token belonging to someone else is what is abused; the attacker's own audit identity is retained, which paradoxically both aids evasion of authorization checks and leaves attacker attribution in logs. The opt-in Keycloak auth manager is not Airflow's default, narrowing the exposed population.

This is a genuine authorization-bypass / privilege-escalation flaw, but the raw CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) overstates real-world risk because it ignores two hard preconditions in the description. Exploitation is NOT unauthenticated in practice: the attacker must already hold their own valid Airflow login AND must separately obtain another subject's Keycloak access or refresh token 'out of band.' That out-of-band token acquisition is a material access-complexity gate, so PR:N/AC:L is questionable - I assess PR:L (attacker's own session required) and AC:H (foreign token must be procured). EPSS is low at 0.21% (11th percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, all consistent with a config-gated, niche-provider issue rather than mass exploitation. Signals are internally consistent (low EPSS, no KEV, no POC, patch available) - this is a real bug worth patching promptly in affected deployments, but it is a 'high CVSS, moderate real-world priority' case, not an internet-wide emergency. Note the vendor 'Information Disclosure' tag understates impact: the fix and description show authorization is made under foreign privileges (I:H), not merely data exposure.

An authenticated Airflow user on a 3.3+ deployment using the Keycloak auth manager logs in normally, then swaps in a higher-privileged colleague's Keycloak access/refresh token (captured via cookie theft, a proxy, shared browser, or another leak) into the separate, unsigned Keycloak cookies. Airflow keeps naming the attacker's own account in the session, audit log, and cache keys while making every authorization decision with the victim's privileges, and the refresh path re-mints the pairing so it persists. No public exploit code is identified at time of analysis; the fix PR includes regression tests but not a weaponized POC.