CVE-2026-68971: Apache Airflow Auth Bypass Vulnerability

CVE-2026-68971 Overview

CVE-2026-68971 is a missing authorization vulnerability [CWE-862] in Apache Airflow's multi-team deployment mode. The asset materialization endpoint (POST /api/v2/assets/{asset_id}/materialize) and the XCom result check on wait_dag_run_until_finished authorized the target Dag without resolving its owning team. Team-aware auth managers such as the Keycloak auth manager consult the DAG:<team> resource, so the team-scoped permission that should gate the request was never evaluated. An authenticated user in one team could trigger Dag runs owned by another team and read another team's XCom values.

Critical Impact
Cross-team Dag execution and XCom data disclosure in Apache Airflow multi-team deployments using team-aware auth managers such as Keycloak.

Affected Products

Apache Airflow versions prior to 3.3.1 running in multi-team mode
Deployments configured with a team-aware auth manager (for example, Keycloak auth manager)
Not affected: deployments using the FAB auth manager, which has no multi-team support

Discovery Timeline

2026-08-12 - CVE-2026-68971 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68971

Vulnerability Analysis

Apache Airflow supports a multi-team deployment mode in which Dags belong to specific teams and authorization decisions are scoped to team membership. A team-aware auth manager distinguishes a team-scoped Dag from a global one through the team field on the Dag. The Keycloak auth manager, for example, checks the DAG:<team> resource when authorizing Dag operations.

Two code sites failed to resolve the target Dag's team before performing the authorization check. The asset materialization endpoint (POST /api/v2/assets/{asset_id}/materialize) and the XCom result check invoked from wait_dag_run_until_finished both consulted only the generic DAG resource. The team-scoped permission that should have gated the request was never evaluated.

An authenticated user assigned to Team A could invoke these endpoints against a Dag owned by Team B. The attacker supplies their own dag_run_id and conf payload when triggering materialization, and can read XCom values produced by another team's workflows.

Root Cause

The root cause is an incomplete authorization pattern at two request-handling sites. Every other authorization site in Airflow resolves the Dag's team before invoking the auth manager, but these two paths passed the Dag identifier without the team context. Team-aware auth managers therefore fell back to a generic DAG resource check that the caller could satisfy through their own team membership.

Attack Vector

Exploitation requires an authenticated Airflow account in any team within a multi-team deployment. The attacker issues a POST request to /api/v2/assets/{asset_id}/materialize referencing an asset associated with another team's Dag, or invokes a workflow that waits on another team's Dag run through wait_dag_run_until_finished. Because network reachability to the Airflow API and low-privileged authenticated access are the only prerequisites, exploitation is straightforward in affected deployments. See the GitHub Pull Request and the Apache Mailing List Thread for technical details.

Detection Methods for CVE-2026-68971

Indicators of Compromise

Requests to POST /api/v2/assets/{asset_id}/materialize where the authenticated principal's team does not match the target Dag's team
Dag runs created with dag_run_id values and conf payloads submitted by users outside the Dag's owning team
XCom reads issued via wait_dag_run_until_finished against Dag runs in another team's namespace

Detection Strategies

Correlate Airflow API access logs with the team membership of the authenticated user and the team ownership of the referenced Dag or asset
Alert on any /api/v2/assets/*/materialize invocation where the caller's team differs from the Dag owner's team
Review auth manager decision logs (for example, Keycloak) for resource checks that resolved to DAG rather than DAG:<team> on materialization and XCom paths

Monitoring Recommendations

Enable verbose audit logging on the Airflow REST API and forward logs to a centralized analytics platform for cross-team access analysis
Track baseline patterns of who materializes which assets and flag deviations that cross team boundaries
Monitor for unusual conf values or dag_run_id patterns that indicate scripted enumeration of assets across teams

How to Mitigate CVE-2026-68971

Immediate Actions Required

Upgrade Apache Airflow to version 3.3.1 or later, which resolves the Dag's team at both authorization sites
Inventory multi-team deployments and confirm whether a team-aware auth manager (such as Keycloak) is in use
Rotate any secrets or sensitive values that may have been exposed through cross-team XCom reads

Patch Information

The fix is included in Apache Airflow 3.3.1. The upstream change resolves the Dag's team at both the asset materialization endpoint and the XCom result check in wait_dag_run_until_finished, ensuring the team-aware auth manager evaluates the correct DAG:<team> resource. Review the GitHub Pull Request and the Openwall OSS Security Post for full remediation context.

Workarounds

If upgrading immediately is not possible, restrict network access to the Airflow API so that only trusted principals can reach materialization and XCom endpoints
Temporarily disable multi-team mode where feasible, or consolidate sensitive Dags into a single trusted team until the patch is deployed
Deployments using the FAB auth manager are not affected and do not require action beyond standard patching hygiene

bash

# Upgrade Apache Airflow to the patched release
pip install --upgrade 'apache-airflow==3.3.1'

# Verify the installed version
airflow version