GPU VulnDB

Database/Control plane, storage & DevOps

Apache Airflow FAB provider: a DAG named 'DAGs' collides with the global all-DAGs permission and escalates privileges

CVSS 8.1CVE-2026-59245Control plane, storage & DevOpscurated

Impact

resource_name() produces the same resource name for a DAG whose dag_id is literally 'DAGs' as it does for the global all-DAGs permission. Granting a low-privileged user per-DAG access_control on that one DAG therefore silently grants them read and edit on every DAG in the deployment. In a shared Airflow that fronts a GPU fleet, per-DAG access control is exactly the boundary between teams; this collapses it, letting a user read other teams' pipeline definitions and connections and edit or trigger their jobs. The trigger is a naming coincidence, so the escalation can exist without anyone having done anything suspicious.

Who can reach it

Network, authenticated - any Airflow user who has been granted per-DAG access to a DAG named 'DAGs' via the FAB auth manager. Exploitation requires no special tooling; the user simply has permissions they should not have.

What to do

Upgrade apache-airflow-providers-fab to 3.7.2 or later, which disambiguates the resource-name collision, then restart the webserver/API server and scheduler. As an immediate check, look for a DAG whose dag_id is 'DAGs' and rename it or remove the per-DAG grants pointing at it; that removes the escalation without an upgrade. Audit which users held that grant and what they could reach.

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.