CVE-2026-76187 in Airflow
Summary
by MITRE • 09/16/2026
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. No allowlist restricts which client ids may authenticate, so the credentials of an unrelated application that happens to share the realm are valid Airflow login credentials, and Airflow mints a signed session token for that application's service account. The endpoint also answers unauthenticated credential guesses against Keycloak under Airflow's identity.
Affects deployments using the Keycloak auth manager whose realm is shared with other confidential clients. The attacker needs valid credentials for any one of those clients, not for Airflow. Resource authorization is still evaluated per subject, so the access gained is whatever that service account holds, plus any endpoint gated only on being authenticated.
Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which accepts only the configured client on that grant.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Apache Airflow Keycloak provider contains a critical authentication bypass vulnerability stemming from an overly permissive configuration in its interaction with the Keycloak identity provider. Specifically, the unauthenticated token endpoint is designed to accept OAuth2 client-credentials grants for any confidential client registered within the same Keycloak realm as Airflow, rather than restricting this access exclusively to the specific client ID configured for Apache Airflow itself. This architectural flaw means that there is no allowlist or strict validation mechanism in place to verify whether the requesting application is authorized to authenticate as an Airflow user. Consequently, any confidential client registered in the shared Keycloak realm can present its own valid credentials to obtain a signed session token from Airflow, effectively impersonating a service account within the Apache Airflow environment without possessing actual Airflow-specific credentials.
This vulnerability allows attackers who possess valid credentials for any unrelated application sharing the same Keycloak realm to gain unauthorized access to Apache Airflow. By leveraging these external credentials against the unauthenticated endpoint, an attacker can mint a signed session token that is accepted by Airflow as legitimate authentication. The operational impact of this flaw depends heavily on the permissions assigned to the compromised service account associated with the exploited client ID. While resource authorization within Airflow remains evaluated per subject and thus limits access to only what that specific service account holds, the attacker gains entry to any endpoints or functionalities gated solely by being authenticated rather than authorized for a specific role. This effectively expands the attack surface significantly, as it allows lateral movement from one application's compromised credentials into the data orchestration platform of Apache Airflow.
From a security standards perspective, this issue aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity, as the system fails to properly verify that the authentication request originates from an authorized entity specific to its own configuration. In terms of MITRE ATT&CK mapping, this vulnerability facilitates Initial Access through Valid Accounts, specifically leveraging legitimate credentials obtained or leaked from a different service within the same identity domain. The lack of strict client ID validation represents a fundamental failure in enforcing least privilege and proper isolation between distinct applications sharing an identity provider infrastructure.
To mitigate this risk, users deploying Apache Airflow with the Keycloak auth manager must ensure that their deployments are not shared across multiple confidential clients unless absolutely necessary, or they should implement additional gateway-level controls to restrict token endpoint access. The primary remediation is to upgrade the apache-airflow-providers-keycloak package to version 0.10.0 or later. This updated version enforces strict validation by accepting client-credentials grants only for the specific configured Airflow client ID, thereby preventing unrelated applications from leveraging their credentials to authenticate as an Airflow service account and restoring proper isolation between identity providers and application-specific authentication flows.