Apache Airflow Keycloak EUVD-2026-102520

Requires all of: [core] multi_team enabled, the Keycloak auth manager configured, and teams provisioned via airflow keycloak-auth-manager create-team (which attached team roles to the shared View resource). The attacker must be an authenticated, provisioned member of at least one team. Specifically, audit-log entries not tied to a Dag, import errors for files with no registered Dag, and reparse views were authorized against View - which every team role can read - instead of an admin-restricted resource. Limiting factors that reduce real-world risk: valid team-member authentication is mandatory (not anonymous/remote-unauthenticated), the single-team/default and non-Keycloak deployments are entirely unaffected, impact is read-only disclosure of audit data (no write/integrity or availability impact), and the fix requires re-running the create-team CLI so the new AdminView resource exists.

This is a medium-severity, access-control information-disclosure flaw (CWE-732, improper permission assignment) whose real-world risk is tightly bounded by its preconditions rather than by broad exploitability. No CVSS vector, EPSS score, SSVC decision, KEV listing, or public POC was provided in the input, so quantitative exploitation signals are entirely absent and cannot be compared - the assessment rests on the description and the vendor patch (PR #73696). Exploitation requires an already-authenticated team member and a very specific deployment: [core] multi_team enabled, the Keycloak auth manager in use, and teams provisioned via the CLI. Under those conditions any team member could read other teams' audit-log events via the UI or event-log API - a confidentiality-only tenant-isolation break, not RCE or privilege escalation. There is no public evidence of exploitation; treat this as a patch-at-normal-cadence multi-tenancy hardening issue rather than an emergency. Note the disagreement between signal availability and severity framing: the vendor assigned no CVSS and provided no exploitation telemetry, so any 'high priority' framing would be unsupported by the data - prioritize based on whether you actually run multi-team Keycloak Airflow.

In an Airflow deployment running multi-team mode with the Keycloak auth manager, a legitimate member of Team A logs into the web UI (or calls the event-log API) and browses audit events belonging to Team B, to which they should have no visibility. Because every team role was granted global read on the shared View resource, cross-team audit data - operational activity, user actions, and metadata for files not tied to a Dag - is exposed. No public exploit code is identified; exploitation is trivial manual browsing once the vulnerable configuration exists.