A newly disclosed vulnerability in Apache Airflow’s FAB (Flask-AppBuilder) provider shows how a single naming collision can quietly unravel an entire permission model.
Tracked as CVE-2026-59245, the flaw allows a user with access to just one specifically named DAG to inherit read/edit rights across every DAG in the deployment a textbook case of privilege escalation hiding in plain sight.
The issue was disclosed by Apache Airflow PMC member Vincent Beck on July 13, 2026, via the users@airflow.apache.org mailing list, and rated moderate severity.
Airflow FAB Flaw
Airflow’s FAB auth manager uses a function called resource_name() to generate permission identifiers for DAG-level access control. The auth manager also reserves a special global resource name representing “all DAGs,” which grants blanket access across the entire DAG catalog.
The bug: if an administrator creates a DAG with the dag_id value “DAGs”, resource_name() generates a resource identifier that is identical to the reserved global all-DAGs permission string.
Since Airflow’s access_control system relies on exact string matching to scope permissions, this collision means the system can no longer distinguish “access to the DAG literally named DAGs” from “access to all DAGs.”
The exploitation path is unsettlingly simple and requires no code injection or credential theft:
- An administrator creates a DAG with
dag_id="DAGs"(perhaps unaware of the collision risk). - A lower-privileged user is granted per-DAG
access_controlpermissions scoped only to that single DAG. - Because of the string collision, Airflow’s authorization layer silently upgrades that grant to the global all-DAGs permission.
- The user now has read/edit access to every DAG in the environment, including sensitive production pipelines they were never meant to touch.
No malicious intent is needed from the administrator; this can happen entirely by accident, which is part of what makes it dangerous in shared or multi-tenant Airflow deployments.
The vulnerability affects all versions of apache-airflow-providers-fab prior to 3.7.2. Any organization using the FAB auth manager for role-based access control in Airflow a common setup for enterprises managing multi-team DAG ownership should treat this as a priority check, particularly if DAG naming isn’t tightly governed.
Security researcher Tran Hieu (h1tr3xnull) is credited with discovering and reporting the flaw. Airflow committer Jarek Potiuk developed the fix, merged via GitHub PR #69106, which disambiguates the resource-name generation logic, preventing DAG-specific names from masquerading as the global permission scope.
Mitigation
- Upgrade
apache-airflow-providers-fabto version 3.7.2 or later immediately. - Audit existing DAGs for any
dag_idmatching reserved or ambiguous strings like “DAGs.” - Review
access_controlgrants across your Airflow instance to confirm no unintended global permissions were inherited before patching. - Treat this as a reminder to periodically audit RBAC configurations in orchestration tools, where naming conventions can have unexpected security implications.
Organizations running FAB-based Airflow deployments should not wait for a scheduled maintenance window; the fix is low-risk, and the exposure, while requiring specific conditions, is trivial to trigger once those conditions exist.