Apache Airflow CVE-2026-59245

Exploitation requires two concrete, non-default conditions: (1) a DAG must exist whose dag_id is exactly the string 'DAGs' (the same value as the reserved global all-DAGs resource name RESOURCE_DAG), and (2) an administrator must grant a lower-privileged FAB user per-DAG access_control on that specific 'DAGs' DAG. The deployment must be using the Apache Airflow FAB auth manager (apache-airflow-providers-fab) below 3.7.2. Given the CVSS vector's PR:L, the attacker must already hold an authenticated low-privileged Airflow account. Limiting factors: the escalation cannot occur unless someone names a DAG 'DAGs' (unusual) and an admin explicitly grants access to it, so an attacker cannot trigger it unilaterally against a default configuration; there is no user-interaction requirement beyond that, and once the grant exists the escalation is automatic and silent.

The vendor CVSS 3.1 score is 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), reflecting network-reachable, low-privilege authenticated abuse with high confidentiality and integrity impact but no availability impact. However, real-world exploitability is meaningfully constrained by two preconditions the attacker does not control: a DAG must exist that is literally named 'DAGs', and an administrator must grant the low-privileged user per-DAG access_control to it. Because these are non-attacker-controlled conditions, I assess attack complexity as higher than the vendor's AC:L (see my assessed vector, AC:H). No EPSS score was provided in the input, and the CVE is not in CISA KEV, so there is no evidence of active exploitation; exploitation status is 'no public exploit identified at time of analysis'. Net: this is a legitimate high-severity privilege-escalation bug worth prioritizing for Airflow operators using the FAB auth manager, but it is a misconfiguration-dependent escalation rather than a mass-exploitable remote flaw - realistic risk is lower than the raw 8.1 suggests.

In an Airflow deployment using the FAB auth manager, an administrator creates or already has a DAG whose dag_id is 'DAGs' and grants a low-privileged analyst per-DAG access to it via access_control. Because the vulnerable resource_name() maps 'DAGs' to the global all-DAGs permission resource, the analyst silently gains read and edit rights over every DAG in the environment, allowing them to view sensitive workflow definitions and modify pipelines they were never meant to touch. No public exploit code is required - the escalation happens automatically once the naming and grant conditions are met.