CVE-2026-76186
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk42th percentile - higher than 42% 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
See all- 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.
- CVE-2026-92228Medium
The Apache Airflow Keycloak provider's multi-team provisioning (`_attach_team_permissions`) granted every team role global read access to audit logs. Deployments enabling multi-team mode with the Keycloak auth manager are affected: any authenticated member of one team could read other teams' audit events through the UI or the event-log API.
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS