GPU VulnDB

Database/Control plane, storage & DevOps

Airflow: asset materialization authorizes the Dag without its team, letting one team trigger another's runs

CVSS 6.5CVE-2026-68971Control plane, storage & DevOpscurated

Impact

POST /api/v2/assets/{asset_id}/materialize and the XCom result check in wait_dag_run_until_finished authorize the target Dag without resolving 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 manager checks the DAG resource rather than DAG:<team> - so the permission meant to gate the call is never consulted. In a multi-team deployment an authenticated user in one team can trigger another team's Dag runs with their own dag_run_id and conf, and read another team's XCom values. On a shared fleet that means running arbitrary configured work under another tenant's pipeline identity and consuming its scheduled capacity. Deployments on the FAB auth manager are unaffected, as it has no multi-team support.

Who can reach it

Any authenticated user in a multi-team Airflow deployment running a team-aware auth manager (for example Keycloak). Network access to the Airflow API plus ordinary credentials is enough.

What to do

Upgrade apache-airflow to 3.3.1 or later, which resolves the Dag's team at both sites, and restart the API server and scheduler. No node-level maintenance required. Review audit and Dag-run history for materialize calls that crossed teams.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.