Airflow Keycloak Provider CVE-2026-76187

Requires the Keycloak auth manager provider (apache-airflow-providers-keycloak < 0.10.0) whose Keycloak realm is SHARED with at least one other confidential client - a non-default multi-tenant realm topology. The attacker must possess valid credentials (client id + secret) for any one of those other confidential clients; they do NOT need Airflow's own credentials or any Airflow account. The vulnerable path is the unauthenticated POST /auth/token client_credentials grant, which lacked a client_id allowlist. Limiting factors: access obtained is scoped to whatever the borrowed service account is authorized for (per-subject authorization is still enforced) plus endpoints gated only on being authenticated; deployments not using the Keycloak auth manager, or using a dedicated single-client realm, are not exposed.

Signals conflict sharply. The vendor CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) treats this as a trivial unauthenticated network compromise, but the description imposes two real preconditions the vector does not capture: (1) the Keycloak realm must be shared between Airflow and at least one other confidential client - a non-default multi-client topology - and (2) the attacker must already hold valid credentials for one of those other clients. That makes it an authentication-context bypass (CWE-287) rather than pure PR:N unauthenticated RCE-style access, so real-world attack complexity is higher than AC:L implies. Impact is also over-stated: the description says resource authorization is still evaluated per subject, so the attacker gains only whatever the borrowed service account holds plus endpoints gated on mere authentication - not guaranteed full C:H/I:H/A:H. Corroborating low-urgency signals: EPSS is 0.19% (9th percentile), the CVE is NOT in CISA KEV, and no public exploit code was identified. The mechanism is simple and well-documented in the patch, but exploitability is bounded by needing pre-existing valid credentials for a co-tenant client, so this is a genuine but conditional issue, not a mass-exploitation 9.8. A secondary risk is the endpoint acting as an unauthenticated oracle for guessing other clients' credentials under Airflow's identity.

In an environment where Airflow's Keycloak auth manager shares its realm with other applications, an attacker who possesses the client id and secret of any one unrelated confidential client (e.g. a compromised or legitimately-held service account for a neighboring app) sends a client_credentials request to Airflow's unauthenticated POST /auth/token. Airflow accepts the foreign client's credentials and mints a signed Airflow session token bound to that service account, granting whatever access that subject holds plus any authenticated-only endpoints. No public POC has been identified, but the fix diff and tests make the exact request shape clear.