EUVD-2026-57268
GHSA-5247-m8w9-2v4m
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network vector (API endpoint), high complexity (requires multi-team mode plus team-aware auth manager), low privilege (any authenticated user), no availability impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
Apache Airflow's 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 its team, unlike every other authorization site. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the DAG resource instead of DAG:<team> -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own dag_run_id and conf, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.
AnalysisAI
Cross-team DAG authorization bypass in Apache Airflow versions prior to 3.3.1 allows authenticated users in one team to trigger DAG runs and read XCom values belonging to other teams. The asset materialization endpoint (POST /api/v2/assets/{asset_id}/materialize) and the XCom check in wait_dag_run_until_finished both passed DagDetails without resolving the DAG's team_name, causing team-aware auth managers (e.g., Keycloak) to evaluate the permission against the global DAG resource instead of the team-scoped DAG:<team> resource. This is a missing authorization flaw (CWE-862) affecting only deployments running multi-team mode with a team-aware auth manager; FAB auth manager deployments are explicitly unaffected. No public exploit code or CISA KEV listing has been identified at time of analysis.
Technical ContextAI
Apache Airflow 3.x introduced a pluggable auth manager interface with optional multi-team mode. Team-aware auth managers such as the Keycloak integration distinguish team-scoped DAGs from global ones by consulting the team_name field of the DagDetails object passed to is_authorized_dag(). When team_name is None (absent), the auth manager evaluates the generic DAG resource permission rather than the team-specific DAG:<team> permission. The affected code paths - the asset materialization route in airflow-core/src/airflow/api_fastapi/core_api/routes/public/assets.py and the XCom wait route in dag_run.py - both constructed DagDetails(id=dag_id) without resolving and supplying the team_name. This omission meant the team-scoped permission gate was never evaluated, silently granting cross-team access. The root cause maps to CWE-862 (Missing Authorization): the authorization check executes, but it checks the wrong resource scope. The CPE string cpe:2.3:a:apache_software_foundation:apache_airflow:*:*:*:*:*:*:*:* covers all versions prior to 3.3.1.
RemediationAI
Upgrade Apache Airflow to version 3.3.1 or later, which resolves the DAG's team at both affected authorization sites by calling DagModel.get_team_name() before constructing the DagDetails object. The upstream fix is available at https://github.com/apache/airflow/pull/70893 and the vendor advisory is at https://lists.apache.org/thread/kfxqqwgojdjdnt6bxg3ord4y41y334fo. If an immediate upgrade is not feasible, a targeted compensating control is to restrict access to the POST /api/v2/assets/{asset_id}/materialize endpoint and the GET /dags/{dag_id}/dagRuns/{dag_run_id}/wait endpoint at the API gateway or reverse-proxy layer for non-administrative roles - this limits lateral movement across teams at the cost of disabling asset materialization functionality for affected users. Alternatively, temporarily disabling multi-team mode eliminates the exploit path entirely but removes team isolation for all users. Neither workaround addresses the underlying authorization flaw; upgrade to 3.3.1 is the only complete remediation.
More in Apache Airflow
View allRemote code execution in Apache Airflow before 3.3.0 lets a DAG author embed a malicious trigger whose attacker-controll
Unsafe deserialization in Apache Airflow 3.3.0's Task SDK allows an authenticated DAG author to cause arbitrary module i
Unsafe deserialization in Apache Airflow 3.0.0 through 3.3.0 allows any DAG author to achieve arbitrary code execution i
Remote code execution in Apache Airflow 3.1.x allows authenticated DAG Authors to execute arbitrary code in the webserve
Command injection in Apache Airflow's BashOperator documentation example allows authenticated attackers to escalate priv
We need to produce a JSON object per the instructions. Let's analyze each field. First, product_name: "1-3 words ONLY.
CVE-2026-30911 is a security vulnerability (CVSS 8.1) that allows any authenticated task instance. High severity vulnera
Information disclosure in Apache Airflow 3.0.0 through 3.1.x stems from incomplete secret masking and under-documented w
Apache Airflow 3.0.0 through 3.1.x exposes JWT authentication tokens in application logs, allowing any authenticated UI
CVE-2026-28779 is a security vulnerability (CVSS 7.5) that allows any application co-hosted under the same domain. High
Apache Airflow before 3.2.0 exposes SQL exception stack traces through API responses despite api/expose_stack_traces=fal
Apache Airflow 3.0.x prior to 3.2.0 allows remote unauthenticated attackers to trigger unauthorized DAG (Directed Acycli
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today