CVE-2026-76187 turns a Keycloak realm design decision into an Airflow authentication boundary failure. Apache Airflow is the open-source platform teams use to develop, schedule and monitor data pipelines, machine-learning jobs, and other workflows. The affected apache-airflow-providers-keycloak package is an independently released provider that lets Airflow delegate identity and permissions to Keycloak; Apache describes this auth manager as alpha/experimental.
The issue matters specifically where Airflow shares a Keycloak realm with other applications. A realm is an identity domain, and a confidential client is an application registered there with a client ID and secret. Those are common arrangements for organisations whose data, platform, analytics, or ML teams use a central Keycloak deployment rather than separate identity systems for each service.
Any realm client could cross Airflow’s login boundary
Before the fix, Airflow’s unauthenticated POST /auth/token endpoint accepted a client_credentials request using caller-supplied credentials and passed them to Keycloak. It did not first verify that the submitted client ID was the client configured for Airflow. As a result, credentials for any confidential client in the same realm—including one belonging to an unrelated internal application—could yield a signed Airflow session JWT for that client’s Keycloak service account.
This is not a route to arbitrary impersonation by itself. The resulting Airflow access is evaluated as that service-account subject, so normal resource authorization remains in force. But it can expose anything that account is allowed to do, as well as endpoints protected only by the fact that a caller is authenticated. An attacker needs valid credentials for one other confidential client in the shared realm, not Airflow’s own client secret; that is a substantially different trust assumption.
The endpoint also let unauthenticated callers submit credential guesses to Keycloak through Airflow. The correction blocks an unconfigured client ID before Airflow contacts Keycloak, both enforcing the intended boundary and avoiding a useful credential-testing path.
Upgrade the provider and examine realm sharing
Apache says versions before 0.10.0 are affected and recommends upgrading apache-airflow-providers-keycloak to 0.10.0 or later. The fixed release was available September 14, 2026; version 0.10.0 requires Apache Airflow 3.0.0 or later. Although the provider changelog says client_credentials support arrived in 0.5.0, the security advisory does not formally narrow its affected range beyond “before 0.10.0.”
The practical first step is to inventory Airflow deployments using this auth manager, upgrade the provider, and confirm the configured Keycloak client ID is the one intended for Airflow. Teams should also map every confidential client sharing that realm, rotate credentials where exposure is uncertain, and reduce service-account permissions to what each integration actually needs. Separating high-trust applications into distinct realms can limit the blast radius of this kind of configuration error.
Apache’s advisory calls the issue moderate and provides no numeric CVSS score, while later database records assign 9.8/critical; Apache does not explain the difference. The public advisory was issued September 15, 2026. The supplied release information also lists CVE-2026-82311 among related fixes, but it is not part of this authentication flaw.
No observed attacks or public exploit
As of September 21, 2026, no exploitation in the wild had been confirmed, and no named incident or campaign was found. No public proof of concept or standalone exploit code has surfaced; the public patch and tests describe the flow but are not a ready-made exploit. The CVE is also not listed in CISA’s KEV catalogue as of that date, though direct retrieval of CISA’s live feed could not be confirmed during research.
This is a focused upgrade, but not one to treat as merely a package-management task: the exposure depends on how identities and client secrets are shared across the realm. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, which helps teams find these less-visible provider dependencies before a shared configuration makes them consequential.
