CVE-2026-76186

CriticalCVSS 9.1

Published: 16/09/2026(UTC)Updated: 17/09/2026(UTC)Translated: 16/09/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.21%

11th percentile - higher than 11% of all known CVEs

Summary

In Apache Airflow Keycloak provider from version 3.3, the user identity is taken from the signed Airflow session token, but the Keycloak access and refresh tokens used for authorization come from separate, unauthenticated cookies and are never checked for consistency with the identity. This allows pairing foreign tokens with one's own session.

Risk Assessment

An attacker can use another subject's Keycloak tokens for authorization while logs and audit name their own account, potentially leading to unauthorized access and hiding actions.

Recommendation

It is recommended to upgrade apache-airflow-providers-keycloak to version 0.10.0 or later, which binds the cookie-supplied tokens to the session identity.

Other vulnerabilities in Apache Airflow Keycloak provider

CVE-2026-76187Critical
In Apache Airflow Keycloak provider, the unauthenticated token endpoint accepts a client-credentials grant for any confidential client registered in the Keycloak realm, not only the client configured for Airflow. The lack of an allowlist allows credentials of another application to be valid Airflow login credentials.

Original NVD description (English source)

Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checks that the two describe the same subject. A user who holds any valid Airflow login of their own, together with another subject's Keycloak access or refresh token obtained out of band, can pair the two: Airflow then 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 original identity carrying the foreign tokens, so the mismatched pairing survives across sessions. Affects deployments running Airflow 3.3 or later with the Keycloak auth manager. Earlier versions carried the Keycloak tokens inside the signed session token, so the binding existed and was lost when they moved into separate cookies. Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which binds the cookie-supplied tokens to the session identity.