Apache Airflow's JWTRefreshMiddleware set the JWT auth cookie without the Secure flag, so deployments running the Airflow API server behind an HTTPS-terminating reverse proxy (e.g. nginx / Envoy / a managed load balancer that terminates TLS and forwards plaintext to the API server, the default cloud-native topology) would have the user's session JWT replayed over any cleartext HTTP request to the same host. A network-positioned attacker (Wi-Fi MITM, hostile LAN, captive-portal proxy) could induce a logged-in user's browser to issue an HTTP request to the deployment's hostname and capture the JWT cookie out of that request, then replay it against the authenticated API. Affects deployments where the Airflow API server is reached through a TLS-terminating proxy and the cookie's secure-by-default protection is load-bearing for session integrity. Users are advised to upgrade to apache-airflow 3.2.2 or later.

Apache Airflow versions 3.0.0 through 3.1.8 DagRun wait endpoint returns XCom result values even to users who only have DAG Run read permissions, such as the Viewer role.This behavior conflicts with the FAB RBAC model, which treats XCom as a separate protected resource, and with the security model documentation that defines the Viewer role as read-only.

Airflow uses the FAB Auth Manager to manage access control on a per-resource basis. The Viewer role is intended to be read-only by default, and the security model documentation defines Viewer users as those who can inspect DAGs without accessing sensitive execution results.

Users are recommended to upgrade to Apache Airflow 3.2.0 which resolves this issue.

Apache Airflow versions 3.1.0 through 3.1.7 /ui/dependencies endpoint returns the full DAG dependency graph without filtering by authorized DAG IDs. This allows an authenticated user with only DAG Dependencies permission to enumerate DAGs they are not authorized to view.

Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.

Impact

Exposure of Sensitive Information:

An information disclosure vulnerability exists in the Apache Airflow UI that allows authenticated users to view Import Errors for DAGs they are not authorized to access.

In affected versions, the Import Errors view does not correctly filter errors based on granular DAG permissions. This means a user with access to only DAGA can view import errors generated by DAGB, DAGC, or system-level DAGs. These error logs often contain file paths, code snippets, or stack traces that reveal the internal structure and logic of restricted DAGs.

Patches

Users should upgrade to Apache Airflow 3.1.7 or later. This version strictly enforces DAG-level permissions on the Import Errors view.

Workarounds

There are no known workarounds other than upgrading.

Resources

CVE-2026-24098 Pull Request #60801 Mailing List Announcement

When a DAG failed during parsing, Airflow’s error-reporting in the UI could include the full kwargs passed to the operators. If those kwargs contained sensitive values (such as secrets), they might be exposed in the UI tracebacks to authenticated users who had permission to view that DAG.

The issue has been fixed in Airflow 3.1.4 and 2.11.1, and users are strongly advised to upgrade to prevent potential disclosure of sensitive information.

API users via /api/v2/dagReports could perform Dag code execution in the context of the api-server if the api-server was deployed in the environment where Dag files were available.

An example dag exampledagdecorator had non-validated parameter that allowed the UI user to redirect the example to a malicious server and execute code on worker. This however required that the example dags are enabled in production (not default) or the example dag code copied to build your own similar dag. If you used the exampledagdecorator please review it and apply the changes implemented in Airflow 3.0.5 accordingly.