Apache Airflow Providers Keycloak
Monthly
Authentication bypass in the Apache Airflow Keycloak auth manager provider (apache-airflow-providers-keycloak below 0.10.0) lets a remote attacker exchange credentials belonging to any confidential client in a shared Keycloak realm for a signed Airflow session token, even though those credentials have nothing to do with Airflow. The unauthenticated POST /auth/token client_credentials grant performed no allowlist check on client_id, so an unrelated application's service-account secret became a valid Airflow login; the resulting access is limited to whatever that service account is authorized for per subject, plus endpoints gated only on being authenticated. Exploitation requires a non-default topology - a Keycloak auth manager deployment whose realm is shared with at least one other confidential client - and the attacker must already hold valid credentials for one of those clients; no public exploit code has been identified at time of analysis, EPSS is low (0.19%, 9th percentile), and a vendor patch is available in provider version 0.10.0.
Privilege escalation in the Apache Airflow Keycloak auth manager (apache-airflow-providers-keycloak) affecting Airflow 3.3 and later lets an authenticated user who already holds a valid Airflow session pair it with another subject's Keycloak access or refresh token - obtained out of band via cookie theft, proxy capture or a leaked token - so Airflow authorizes their requests with the foreign token's privileges while the audit log, cache keys and session identity continue to name the attacker's own account. The official CVSS of 9.1 overstates practical risk: exploitation requires both a valid Airflow login and a genuine (not forged) Keycloak token belonging to someone else, and the opt-in Keycloak auth manager is not Airflow's default authentication backend, so the independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N rather than AV:N/AC:L/PR:N. There is no public exploit code and no confirmed active exploitation (EPSS 0.21%, 11th percentile); upgrading the provider to 0.10.0 or later restores the subject binding between session and Keycloak tokens.
Authentication bypass in the Apache Airflow Keycloak auth manager provider (apache-airflow-providers-keycloak below 0.10.0) lets a remote attacker exchange credentials belonging to any confidential client in a shared Keycloak realm for a signed Airflow session token, even though those credentials have nothing to do with Airflow. The unauthenticated POST /auth/token client_credentials grant performed no allowlist check on client_id, so an unrelated application's service-account secret became a valid Airflow login; the resulting access is limited to whatever that service account is authorized for per subject, plus endpoints gated only on being authenticated. Exploitation requires a non-default topology - a Keycloak auth manager deployment whose realm is shared with at least one other confidential client - and the attacker must already hold valid credentials for one of those clients; no public exploit code has been identified at time of analysis, EPSS is low (0.19%, 9th percentile), and a vendor patch is available in provider version 0.10.0.
Privilege escalation in the Apache Airflow Keycloak auth manager (apache-airflow-providers-keycloak) affecting Airflow 3.3 and later lets an authenticated user who already holds a valid Airflow session pair it with another subject's Keycloak access or refresh token - obtained out of band via cookie theft, proxy capture or a leaked token - so Airflow authorizes their requests with the foreign token's privileges while the audit log, cache keys and session identity continue to name the attacker's own account. The official CVSS of 9.1 overstates practical risk: exploitation requires both a valid Airflow login and a genuine (not forged) Keycloak token belonging to someone else, and the opt-in Keycloak auth manager is not Airflow's default authentication backend, so the independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N rather than AV:N/AC:L/PR:N. There is no public exploit code and no confirmed active exploitation (EPSS 0.21%, 11th percentile); upgrading the provider to 0.10.0 or later restores the subject binding between session and Keycloak tokens.