Apache Airflow CVE-2026-68971

Exploitation requires all of the following: (1) the Airflow deployment must be running in multi-team mode; (2) a team-aware auth manager must be configured - the vulnerability description explicitly names the Keycloak auth manager as an example, and confirms FAB auth manager deployments are entirely unaffected; (3) the attacker must hold a valid authenticated session in Airflow (any team membership suffices); (4) the target DAG must be team-scoped (i.e., have a non-null team_name). If any of these conditions is absent - particularly the team-aware auth manager requirement - the vulnerability cannot be triggered. Exploitation is limited to the two specific API endpoints: POST /api/v2/assets/{asset_id}/materialize and the XCom check within GET /dags/{dag_id}/dagRuns/{dag_run_id}/wait.

Real-world risk is conditional: exploitation requires an authenticated session, a non-default multi-team deployment, and a team-aware auth manager - FAB deployments (the default for most Airflow installations) are completely unaffected. For environments that DO meet these conditions, the practical impact is significant: an attacker with any Airflow account can pivot across team boundaries, trigger arbitrary DAG runs with attacker-controlled conf payloads, and exfiltrate sensitive inter-task data stored in XCom. The CVSS score was not provided by NVD at time of analysis; this assessment independently assigns the vector as AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N - high complexity because the exploitation window is limited to the specific multi-team-plus-team-aware-auth configuration. No EPSS score is available. No KEV listing and no public POC have been identified, suggesting exploitation has not yet been observed in the wild. The net priority is elevated for Airflow deployments using Keycloak or similar team-aware auth managers in multi-tenant environments, but negligible for the broader population of FAB-based deployments.

An authenticated Airflow user on Team A, with no permissions on Team B's DAGs, sends a POST request to /api/v2/assets/{asset_id}/materialize where the asset is associated with a Team B DAG, supplying a custom dag_run_id and conf payload. Because the authorization check omits the team_name, the Keycloak auth manager approves the request as if the DAG were global, and the DAG run is triggered under Team B's context with the attacker's conf. The attacker then polls the wait_dag_run_until_finished endpoint to read Team B's XCom output values, exfiltrating inter-task data. No public exploit code exists at time of analysis, but the fix diff and advisory provide sufficient implementation detail for a technically capable attacker to reproduce the condition.