CVE-2026-68971: 
Homebrew vulnerability analysis and mitigation

CVE-2026-68971 is a cross-team authorization bypass vulnerability in Apache Airflow affecting the asset materialization endpoint (POST /api/v2/assets/{asset_id}/materialize) and the XCom result check in wait_dag_run_until_finished. It impacts all versions of Apache Airflow (apache-airflow) before 3.3.1 and was publicly disclosed on August 12, 2026. The vulnerability is classified as Moderate severity with a CVSS v3.1 base score of 6.5 (Apache Advisory, GitHub Advisory). Only deployments running multi-team mode with a team-aware auth manager (e.g., Keycloak) are affected; deployments using the FAB auth manager are unaffected (Openwall).

The root cause is a missing authorization check (CWE-862): two code paths — materialize_asset and the XCom-specific check in wait_dag_run_until_finished — construct DagDetails(id=dag_id) without resolving the DAG's team_name, unlike every other authorization site in the codebase which calls DagModel.get_team_name() (GitHub PR). A team-aware auth manager such as Keycloak uses the team_name field to distinguish a team-scoped DAG resource (DAG:<team>) from a global one (DAG); omitting it causes the authorization check to evaluate against the wrong resource scope, effectively bypassing team-scoped permissions (Openwall). In wait_dag_run_until_finished, the route dependency already resolves the team for the RUN check, but the XCom check in the same handler did not, creating an internal inconsistency. The attack requires only valid credentials (low privileges) and is exploitable over the network with low complexity (GitHub Advisory).

An authenticated user belonging to one team in a multi-team Airflow deployment can trigger DAG runs belonging to another team by supplying arbitrary dag_run_id and conf parameters to the asset materialization endpoint, and can read XCom values produced by another team's DAG runs (Apache Advisory). The confidentiality impact is high — sensitive pipeline outputs (XCom values) can be read across team boundaries — while integrity and availability are not directly affected (GitHub Advisory). The scope is limited to multi-team deployments using team-aware auth managers; single-team or FAB-managed deployments are not at risk.

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is approximately 0.146% (0.328% per GitHub Advisory), placing it in the lower percentiles for near-term exploitation likelihood (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a valid authenticated account within the Airflow deployment, limiting the attacker pool to insiders or compromised credentials.

1. Reconnaissance: Identify an Apache Airflow deployment running in multi-team mode with a team-aware auth manager (e.g., Keycloak) and a version prior to 3.3.1. Confirm multi-team mode is active by observing team-scoped DAG resource naming conventions.
2. Obtain credentials: Acquire valid Airflow credentials for a user belonging to Team A (e.g., through legitimate access or credential compromise).
3. Identify target DAG: Enumerate or guess the dag_id of a DAG belonging to Team B that the attacker should not have access to.
4. Trigger unauthorized DAG run: Send a crafted HTTP POST request to POST /api/v2/assets/{asset_id}/materialize using Team A credentials, where the resolved asset maps to a DAG owned by Team B. Supply a custom dag_run_id and conf payload. Because the authorization check omits team_name, the auth manager evaluates the request against the global DAG resource rather than DAG:<team_b>, and the request succeeds.
5. Read cross-team XCom values: Poll the wait_dag_run_until_finished endpoint for the triggered DAG run. The XCom authorization check similarly omits team_name, allowing the attacker to read XCom output values produced by Team B's DAG run (GitHub PR, Openwall).

• Network: Unexpected POST /api/v2/assets/{asset_id}/materialize requests from users whose team does not own the DAG associated with the target asset; repeated polling of wait_dag_run_until_finished endpoints for DAGs outside the authenticated user's team scope.
• Logs: Airflow API access logs showing cross-team DAG run triggers — specifically, dag_run_id values created by users from a different team than the DAG owner; XCom read events in audit logs for DAGs not belonging to the requesting user's team.
• Application Behavior: DAG runs appearing in Team B's namespace with dag_run_id or conf values not generated by Team B's users or automation; unexpected DAG executions with externally supplied configuration parameters.

Upgrade Apache Airflow to version 3.3.1 or later, which resolves the DAG's team at both the materialize_asset and wait_dag_run_until_finished authorization sites using DagModel.get_team_name() (Apache Advisory, GitHub PR). As a temporary workaround if immediate upgrade is not possible, restrict network access to the POST /api/v2/assets/{asset_id}/materialize endpoint and limit access to wait_dag_run_until_finished functionality to authorized teams only via network-level controls. Additionally, review audit logs for unauthorized cross-team DAG run triggers or XCom reads in multi-team deployments using team-aware auth managers (Feedly).

The vulnerability was reported by finder @haoxucu and remediated by Apache Airflow maintainer Jarek Potiuk, with the fix developed using Claude Opus 5 AI assistance and reviewed by multiple Airflow committers before merge (Openwall, GitHub PR). The fix was milestoned for Airflow 3.3.1 and backported to the v3-3-test branch. Community discussion on the PR noted the underlying design issue — that DagDetails(id=...) makes the unscoped form the easy default — and suggested a future DagDetails.for_dag(dag_id, *, session) constructor as a guardrail to prevent similar regressions (GitHub PR).