CVE-2026-68971: 
Apache Airflow 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. The flaw allows authenticated users in one team to trigger DAG runs belonging to another team and read cross-team XCom values in multi-team deployments using a team-aware auth manager. All Apache Airflow versions before 3.3.1 are affected; deployments using the FAB auth manager are not impacted. Disclosed on August 12, 2026, it carries a CVSS v3.1 base score of 6.5 (Medium) (Apache Advisory, Github Advisory).

The root cause is CWE-862 (Missing Authorization): two code paths — materialize_asset and the XCom 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 and passes the result (GitHub PR). A team-aware auth manager (e.g., Keycloak) uses the team_name field to select the correct resource scope — DAG:<team> for team-scoped DAGs versus plain DAG for global ones — so omitting it causes the authorization check to evaluate against the wrong resource scope, effectively bypassing team-level access controls (oss-security). The wait_dag_run_until_finished handler is a particularly clear illustration: its route dependency already resolves the team for the RUN check, but the XCom-specific check in the same handler disagreed about the scope of the same DAG (GitHub PR). The fix resolves the team at both sites using DagModel.get_team_name(dag_id, session=session), reusing the existing request session.

In multi-team Apache Airflow deployments using a team-aware auth manager, an authenticated but lower-privileged user can trigger DAG runs belonging to another team by supplying arbitrary dag_run_id and conf parameters, and can read XCom values produced by another team's DAG runs (Apache Advisory). The confidentiality impact is high — sensitive pipeline configuration data and inter-task communication values (XCom) from other teams are exposed — while integrity and availability are not directly affected by this vulnerability (Github Advisory). The vulnerability is scoped to deployments running multi-team mode with a team-aware auth manager such as Keycloak; single-team deployments and those using the FAB auth manager are unaffected.

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (oss-security). The vulnerability requires valid credentials (low privileges), making it accessible only to authenticated users, which limits opportunistic exploitation. The EPSS score is approximately 0.146% (0.00146), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported.

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 the deployment exposes the REST API v2 endpoints.
2. Obtain credentials: Authenticate to the Airflow instance as a legitimate user belonging to Team A. Obtain a valid session token or API key.
3. Enumerate target DAGs: Identify DAG IDs belonging to Team B (another team) through any available means — e.g., error messages, documentation, or partial API responses that leak DAG identifiers.
4. Trigger cross-team DAG run: Send a crafted HTTP POST request to POST /api/v2/assets/{asset_id}/materialize where the resolved asset maps to a DAG owned by Team B, supplying custom dag_run_id and conf values. Because the authorization check omits the team field, the request is evaluated against the global DAG resource rather than DAG:<team_b>, bypassing the team-scoped permission gate.
5. Read cross-team XCom values: Poll the wait_dag_run_until_finished endpoint for the triggered DAG run. The XCom authorization check in this handler also omits the team field, allowing the attacker to read XCom values produced by Team B's tasks.
6. Exfiltrate data: Extract sensitive pipeline configuration, secrets passed via conf, or inter-task data from XCom values belonging to Team B (oss-security, GitHub PR).

• Network: Unexpected HTTP POST requests to /api/v2/assets/{asset_id}/materialize from users whose team does not own the asset's associated DAG; API calls to wait_dag_run_until_finished for DAG runs belonging to a different team than the authenticated user.
• Logs: Airflow API access logs showing a user from Team A successfully triggering DAG runs or reading XCom values for DAGs scoped to Team B; auth manager logs (e.g., Keycloak) showing authorization decisions made against the plain DAG resource rather than DAG:<team> for team-scoped DAGs.
• Application Behavior: DAG runs appearing in Team B's namespace with dag_run_id or conf values not generated by Team B's workflows; unexpected XCom reads recorded for cross-team DAG runs in Airflow's metadata database.

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 (Apache Advisory, GitHub PR). If an 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 to only authorized team members through network-level controls or API gateway policies. Additionally, review audit logs for unauthorized cross-team DAG run triggers or XCom reads in multi-team deployments using team-aware auth managers such as Keycloak.

The vulnerability was credited to researcher @haoxucu (finder) and remediated by Jarek Potiuk (Apache Airflow committer), with the fix co-developed using Claude Opus 5 AI tooling and reviewed by human maintainers before merging (oss-security, GitHub PR). The NixOS security tracker opened a tracking issue for Apache Airflow packages affected by vulnerabilities fixed in 3.3.1, indicating downstream ecosystem awareness. Community discussion noted the architectural risk of DagDetails(id=...) making the unscoped (insecure) form the easiest to write, with a suggestion to introduce a DagDetails.for_dag(dag_id, *, session) constructor to prevent similar regressions in the future (GitHub PR).