Description

Apache Airflow's `/assets/events` API returned asset events for every Dag in the deployment, with no filter restricting them to the Dags the caller is authorized to read. Any authenticated user holding asset-read access could therefore enumerate asset events — including the source Dag ID, task ID, run ID and event timestamps — for Dags they have no permission to see. Because the filter was also absent from the count query, `total_entries` and pagination disclosed the existence of hidden Dags even without inspecting individual rows. Deployments are affected whenever per-Dag access control is used to separate teams or tenants; no special configuration is required. Upgrade to apache-airflow 3.3.2 or later.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-21T15:17:31.360Z",
  "pubdate": "2026-09-21T15:17:31.360Z",
  "executiveSummary": "A broken access control vulnerability exists in Apache Airflow where the /assets/events API endpoint fails to implement proper authorization filters for DAG-level access.\nThis vulnerability allows any authenticated user with asset-read permissions to enumerate sensitive metadata regarding assets and their associated DAGs, regardless of the user's explicit permissions for those specific DAGs.\nThe flaw impacts multi-tenant environments or deployments utilizing granular per-DAG access control, potentially leading to unauthorized information disclosure of deployment structures, task execution history, and internal workflow metadata.\nThe issue stems from a lack of server-side filtering on the API response and the total_entries count query, allowing attackers to discover the existence of hidden DAGs through pagination and direct inspection.\nExploitation requires the attacker to be an authenticated user with base asset-read privileges; no special configuration is needed to trigger the flaw, as it is a core logic error in the API implementation.",
  "technicalDetails": "The vulnerability resides within the Apache Airflow /assets/events API endpoint. The root cause is a deficiency in the backend query logic that fails to enforce Row-Level Security (RLS) or attribute-based access control when retrieving asset event logs. Specifically, the API returns a comprehensive list of all asset events across the entire deployment, neglecting to intersect the requested data with the authorization context of the calling user.\nBecause the query logic fails to restrict the result set to authorized DAGs, the API response exposes sensitive internal metadata, including the source DAG ID, task ID, run ID, and event timestamps. This information is critical in environments where DAG access is siloed between teams or tenants for compliance or security isolation. An attacker can leverage this to map the entire DAG landscape of the Airflow instance, effectively bypassing intended visibility constraints.\nThe exploitation flow is straightforward and does not require complex payloads or high-privilege credentials. An authenticated user possessing minimal asset-read permissions can send a GET request to /assets/events. The server executes a database query that ignores the user's permission scope, returning the full dataset. Furthermore, the vulnerability extends to the API's pagination and metadata functionality; the total_entries field and associated pagination controls disclose the existence and count of DAGs even if the attacker does not attempt to view individual row details, facilitating reconnaissance of hidden or restricted workflows.\nThe impact is significant in multi-tenant environments where tenant isolation relies on Airflow's per-DAG access control features. By enumerating these events, an attacker can reconstruct the execution timing and operational dependencies of workflows they are not authorized to access. This leak of internal architectural data can provide a roadmap for further, more targeted attacks. The issue is persistent across all deployments utilizing per-DAG access controls and requires no specialized misconfiguration to manifest, as it is an inherent flaw in the API's handling of authorization context for assets."
}