CVE-2026-68971: 
Homebrew Schwachstellenanalyse und -minderung

CVE-2026-68971 is a cross-team authorization bypass vulnerability in Apache Airflow affecting all versions before 3.3.1. The flaw exists in two API endpoints — the asset materialization endpoint (POST /api/v2/assets/{asset_id}/materialize) and the XCom result check in wait_dag_run_until_finished — which fail to include the DAG's team when performing authorization checks, allowing authenticated users to cross team boundaries in multi-team deployments. It was disclosed on August 12, 2026, with a patch released in Apache Airflow 3.3.1. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, Openwall).

The root cause is CWE-862 (Missing Authorization): two code paths in Airflow's API layer construct DagDetails(id=dag_id) without populating the team_name field, whereas every other authorization call site resolves the team via DagModel.get_team_name() and passes it along (Github PR). A team-aware auth manager such as 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 (Openwall). 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 omitted the team, creating an internal inconsistency within a single request handler (Github PR). Exploitation requires only a valid authenticated session; no elevated privileges are needed beyond belonging to any team in a multi-team deployment.

In multi-team Apache Airflow deployments using a team-aware auth manager (e.g., Keycloak), an authenticated user from one team can trigger DAG runs belonging to another team by supplying an arbitrary dag_run_id and conf payload to the asset materialization endpoint, and can read XCom values produced by another team's DAG runs (Openwall). The confidentiality impact is high — sensitive pipeline outputs (XCom values) from other teams are exposed — while integrity is partially affected through unauthorized DAG run triggering with attacker-controlled configuration. Availability is not impacted. Deployments using the FAB auth manager are entirely unaffected, as it has no multi-team support (Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.146% (4th percentile), indicating a low near-term exploitation probability (Github Advisory). Exploitation is limited to authenticated users in multi-team deployments with a team-aware auth manager, which constrains the attack surface considerably. The vulnerability was discovered by @haoxucu and remediated by Jarek Potiuk (Openwall).

1. Reconnaissance: Identify an Apache Airflow deployment running in multi-team mode with a team-aware auth manager (e.g., Keycloak) and version prior to 3.3.1. Obtain valid credentials for any team within the deployment.
2. Enumerate target DAGs: Use the Airflow REST API (e.g., GET /api/v2/dags) with your own team's credentials to discover DAG IDs belonging to other teams, or infer them through naming conventions.
3. Trigger cross-team DAG run via asset materialization: Send a crafted POST /api/v2/assets/{asset_id}/materialize request where the resolved DAG belongs to a different team, supplying a custom dag_run_id and conf. Because the endpoint omits team_name in its authorization check, the team-scoped permission is never consulted and the request succeeds.
4. Read cross-team XCom values: Call the wait_dag_run_until_finished endpoint for a DAG run belonging to another team. The XCom result check in this handler also omits team validation, allowing the attacker to read XCom values produced by the other team's tasks.
5. Exfiltrate data: Extract sensitive pipeline outputs (credentials, intermediate data, configuration values) stored in XCom from the target team's DAG runs (Github PR, Openwall).

• Network/API Logs: Authenticated API requests to POST /api/v2/assets/{asset_id}/materialize or wait_dag_run_until_finished endpoints where the requesting user's team does not match the team owning the resolved DAG; look for cross-team DAG ID patterns in request parameters.
• Airflow Audit Logs: DAG run creation events (dag_run_id entries) initiated by users from a different team than the DAG owner; unexpected conf values in DAG run records not consistent with normal team workflows.
• Application Logs: Auth manager authorization decisions showing DAG resource checks (without team scope) for DAGs that should require DAG:<team> scoped checks, indicating the unpatched code path was exercised.
• XCom Access: Unexpected XCom read events for DAG runs belonging to teams other than the authenticated user's team, visible in Airflow's task instance and XCom audit trails.

Upgrade to Apache Airflow 3.3.1 or later, which resolves the DAG's team at both the asset materialization and XCom result check endpoints by calling DagModel.get_team_name() before constructing DagDetails (Apache Advisory, Github PR). If an immediate upgrade is not feasible, restrict access to the POST /api/v2/assets/{asset_id}/materialize endpoint and related XCom APIs through network-level controls, reverse proxy rules, or API gateway policies to limit exposure in multi-team environments. Deployments using the FAB auth manager require no action, as they are unaffected by this vulnerability.

The vulnerability was reported to the Apache security team by researcher @haoxucu and remediated by Apache Airflow maintainer Jarek Potiuk, with the fix authored with assistance from Claude Opus 5 AI tooling and reviewed by multiple Airflow committers before merge (Github PR). The disclosure followed standard coordinated vulnerability disclosure via the Apache security mailing list and oss-security, with the advisory published on August 12, 2026 (Openwall). Community discussion noted the architectural insight that DagDetails(id=...) makes the unscoped (vulnerable) 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).