Apache Airflow, versions before 2.6.3, is affected by a vulnerability that allows an unauthorized actor to gain access to sensitive information in Connection edit view. This vulnerability is considered low since it requires someone with access to Connection resources specifically updating the connection to exploit it. Users should upgrade to version 2.6.3 or later which has removed the vulnerability.
The Apache Airflow connections API did not mask the apprise provider's config connection extra, which can embed notification-service credentials. A user with permission to read connections could retrieve it in cleartext, although Airflow 3 treats connection credentials as write-only.
Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.
Apache Airflow's public Import Errors API returns the raw parse-failure stack trace to any user with the ImportError.canread permission when the failing file has no registered DAG. This happens when a file fails to parse before any DAG is defined, or when all of its previously registered DAGs are removed but the parse error remains. Users who should not see that file's details can read stack traces that may expose file paths and code.
Users are advised to upgrade to Apache Airflow 3.4.0 or later, which restricts these stack traces to users with the new IMPORTERRORSALL permission.
Apache Airflow did not reject reserved serialization keys inside a Dag run's conf. A user allowed to trigger a Dag that uses a deadline alert with an asynchronous callback could pass a conf that, once the deadline was missed, either crashed the scheduler repeatedly or was rebuilt into objects inside the Triggerer. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Apache Airflow's audit log stored Connection and Variable secret values in cleartext in the Log.extra column because the secrets masker matched only on configured sensitive key names. An authenticated low-privilege user with read access to the event-log / audit API — with no prior access to the affected connection or variable — could read those rows and recover the credentials verbatim. Users should upgrade to apache-airflow 3.4.0 or later, which masks these values and restricts the affected audit rows to authorized users. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.
Apache Airflow's CLI records its arguments in the audit log but masks secrets by argument position, so some supported command shapes leave secrets in cleartext, for example a trailing --description on Variable commands, --conn-extra, and the inline --password of airflow keycloak-auth-manager commands. A user who can read audit events but is denied Variable and Connection access can retrieve those values through the event-log API.
Users of apache-airflow are recommended to upgrade to 3.4.0 or later. Audit-log entries written before the upgrade keep the cleartext values: purge the affected entries and rotate the secrets they contain. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.
Severity: low
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's logout endpoint attempted to revoke the presented token on the server, but any failure during revocation was silently ignored and logout still reported success. When the auth manager redirects logout to an external logout URL (for example the FAB or Keycloak auth managers), server-side revocation is the only thing that invalidates the Airflow token; it failed on database errors and, reliably, for tokens from an external issuer accepted via [apiauth] trustedjwksurl whose token identifier is longer than 32 characters. Anyone holding a copy of a user's token from before logout could keep using it against the Airflow API until it expired. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
Claude Security Scans (tool) Pierre Jeambrun (remediation developer) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/73562 https://github.com/apache/airflow/pull/73788 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-113508
Severity: moderate
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's secrets masker stopped descending into nested structures after five levels, so a secret registered with the masker — for example a Connection password or a Variable value — that appeared more than five containers deep under non-sensitive keys was shown in cleartext in task logs and rendered template fields. A user who can read task logs or rendered templates, but is not meant to see those secrets, could read them. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
Gjoko Krstic, Zero Science Lab (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/73793 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-113504
Severity: low
Affected versions:
- Apache Airflow 3.3.0 before 3.4.0
Description:
Apache Airflow's asynchronous connection test checked permissions when the test was queued — only create permission when the connection ID did not exist yet — but, when the test completed with commitonsuccess, wrote the tested connection under that ID. A user allowed to create but not edit connections could overwrite a connection someone else had created in the meantime. Only deployments that enable the non-default [core] testconnection setting are affected. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
Evan Ricafort (@evanricafort) of Invalid Web Security (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/74837 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-111455
Severity: low
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's asset API endpoints returned the IDs of Dags that are scheduled on, produce, or consume an asset without checking whether the caller may read those Dags. An authenticated user with asset read access could learn the IDs of Dags they are not authorized to see. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
Zhixi "Jace" Sun, independent security researcher (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/74836 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-111454
Severity: low
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's secrets masker matched sensitive key names only in their snakecase form, so values stored under camelCase keys such as privateKey, connectionString, webhookUrl or accessKey — for example in a Connection's extra or a Variable — were not redacted in task logs, rendered template fields or API responses. A user who can read task logs or rendered templates, but is not meant to see those credentials, could read them in cleartext. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
Anass Bali / 0xbaas (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/74840 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-111452
Severity: moderate
Affected versions:
- Apache Airflow 3.0.0 before 3.4.0
Description:
Apache Airflow's Task Execution API stored XCom values written by a task without the reserved-key check applied elsewhere, so a Dag author's task could write an XCom that, when a user later viewed it through the API with deserialization enabled, made the API server instantiate classes from the airflow. namespace with arguments the Dag author chose. This is an incomplete fix for CVE-2026-59242: users who applied that fix in apache-airflow 3.3.1 remain affected through this route and should upgrade to apache-airflow 3.4.0 or later.
Credit:
Qi Qin of depthfirst (finder) Hama1cco (finder) Zhixi "Jace" Sun, independent security researcher (finder) Michael Lip (theluckystrike) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72718 https://github.com/apache/airflow/pull/74829 https://www.cve.org/CVERecord?id=CVE-2026-59242 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-111421
Severity: moderate
Affected versions:
- Apache Airflow 3.2.0 before 3.4.0
Description:
Apache Airflow did not reject reserved serialization keys inside a Dag run's conf. A user allowed to trigger a Dag that uses a deadline alert with an asynchronous callback could pass a conf that, once the deadline was missed, either crashed the scheduler repeatedly or was rebuilt into objects inside the Triggerer. Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
Jarek Potiuk (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/74834 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-111395
Severity: important
Affected versions:
- Apache Airflow before 3.4.0
Description:
The Apache Airflow connections API did not mask the apprise provider's config connection extra, which can embed notification-service credentials. A user with permission to read connections could retrieve it in cleartext, although Airflow 3 treats connection credentials as write-only.
Users are advised to upgrade to apache-airflow 3.4.0 or later.
Credit:
JelyFishhhhhh (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/73794 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-107474
Severity: low
Affected versions:
- Apache Airflow 3.0.5 before 3.4.0
Description:
The exampledagdecorator example Dag shipped with Apache Airflow validated an IP address fetched over HTTP with Python's ipaddress module and then placed it into a shell command. ipaddress accepts IPv6 zone identifiers containing arbitrary characters, so when example Dags are loaded (loadexamples enabled), a user who can trigger that Dag with a custom url parameter could point it at a server whose response injects shell commands run on the worker. This is an incomplete fix for CVE-2025-54941; users who upgraded for CVE-2025-54941 should upgrade again. Users are advised to upgrade to apache-airflow 3.4.0 or later, or to disable example Dags (loadexamples = False), which is recommended for production.
Credit:
Andrew Rukin (Arenadata) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/73787 https://www.cve.org/CVERecord?id=CVE-2025-54941 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-101031
Severity: important
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's scheduler fully deserializes XCom values written by task code while evaluating task dependencies. A Dag author, who controls what a task writes to XCom, therefore controls data that is deserialized inside the scheduler process - a context the Airflow security model reserves for code installed by the Deployment Manager, above the worker-scoped execution capability a Dag author is documented to have. Deployments that treat Dag authors as less trusted than Deployment Managers are affected, and the scheduler must be evaluating a task dependency that reads a task-written XCom value. Users of apache-airflow are recommended to upgrade to version 3.4.0 or later, which restricts dependency evaluation to primitive XCom values.
Credit:
Claude Security Scans (tool) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72718 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-86829
Severity: important
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's CeleryExecutor ran callback workloads (ExecuteCallback, used for deadline-alert callbacks) without validating the workload's authentication token. Anyone able to write to the Celery broker could enqueue a forged callback and execute arbitrary code on every CeleryExecutor worker, without Airflow credentials. Deployments using the CeleryExecutor are affected.
Users are advised to upgrade to apache-airflow 3.4.0 or later, in which the worker claims the callback through the Execution API, validating the token, before running it.
Credit:
Or Sahar (Reflectiz) (finder) Sean Ghaeli (remediation developer)
References:
https://github.com/apache/airflow/pull/71192 https://www.cve.org/CVERecord?id=CVE-2020-11981 https://github.com/apache/airflow/pull/70927 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-68982
Severity: moderate
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's audit log stored Connection and Variable secret values in cleartext in the Log.extra column because the secrets masker matched only on configured sensitive key names. An authenticated low-privilege user with read access to the event-log / audit API — with no prior access to the affected connection or variable — could read those rows and recover the credentials verbatim. Users should upgrade to apache-airflow 3.4.0 or later, which masks these values and restricts the affected audit rows to authorized users.
Credit:
Eunho Kim (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/68049 https://github.com/apache/airflow/pull/70759 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-50204
Severity: low
Affected versions:
- Apache Airflow before 3.4.0
Description:
Apache Airflow's public Import Errors API returns the raw parse-failure stack trace to any user with the ImportError.canread permission when the failing file has no registered DAG. This happens when a file fails to parse before any DAG is defined, or when all of its previously registered DAGs are removed but the parse error remains. Users who should not see that file's details can read stack traces that may expose file paths and code.
Users are advised to upgrade to Apache Airflow 3.4.0 or later, which restricts these stack traces to users with the new IMPORTERRORSALL permission.
Credit:
se1en (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/69790 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-40913
Apache Airflow 2.4.0, and versions before 2.9.3, has a vulnerability that allows authenticated DAG authors to craft a docmd parameter in a way that could execute arbitrary code in the scheduler context, which should be forbidden according to the Airflow Security model. Users should upgrade to version 2.9.3 or later which has removed the vulnerability.
Apache Airflow 2.4.0, and versions before 2.9.3, has a vulnerability that allows authenticated DAG authors to craft a docmd parameter in a way that could execute arbitrary code in the scheduler context, which should be forbidden according to the Airflow Security model. Users should upgrade to version 2.9.3 or later which has removed the vulnerability.
Apache Airflow 2.4.0, and versions before 2.9.3, has a vulnerability that allows authenticated DAG authors to craft a docmd parameter in a way that could execute arbitrary code in the scheduler context, which should be forbidden according to the Airflow Security model. Users should upgrade to version 2.9.3 or later which has removed the vulnerability.
Apache Airflow's asset queued-events DELETE endpoints checked the caller's Dag-axis permission with READ instead of EDIT. Any authenticated user who could read a Dag could therefore delete that Dag's queued asset events, silently suppressing asset-triggered scheduling for it — a state-changing action gated on a read-only permission. Deployments are affected whenever asset-triggered scheduling is in use and Dag read access is granted more widely than Dag edit access, which is the normal RBAC arrangement; no special configuration is required. Upgrade to apache-airflow 3.3.2 or later.
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, totalentries 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.
Apache Airflow's environment-variable secrets backend resolved a team-scoped Connection or Variable from the wrong team's scope. The guard meant to prevent this only ran when no team scope was supplied, and its pattern could not match a team name containing an underscore, which team names are allowed to contain. When the guard did not apply, the lookup fell through to an unconditional global read that resolved the stored AIRFLOWCONN<TEAM><ID> variable regardless of which team asked. In multi-team mode an authenticated user of one team could therefore have POST /api/v2/connections/test resolve another team's Connection and authenticate outward with that team's credentials; the endpoint uses the credentials rather than returning them. Exploitation requires [core] multiteam enabled, [core] testconnection set to Enabled (it ships Disabled), team-scoped secrets provisioned as environment variables in the API-server process, and knowledge of the encoded identifier. Redirecting the test at an attacker-controlled host is separately blocked. Users are advised to upgrade to apache-airflow 3.3.1 or later.
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 Backfill API authorized a request against a Dag id supplied by the caller whenever the backfillid path segment failed to parse. The authorization dependency parsed it with int() while the route handler parsed it as pydantic's NonNegativeInt, which accepts values int() rejects (1.0 coerces to 1); FastAPI resolves dependencies before endpoint validation, so the two acted on different Dags. An authenticated user holding edit permission on any single Dag could therefore read, pause and cancel backfills belonging to any other Dag, including moving another Dag's queued runs to failed. No non-default configuration is required and backfill ids are sequential, so finding a target is trivial. Users are advised to upgrade to apache-airflow 3.3.1 or later, which parses the backfill id with the same type the routes declare.
Apache Airflow wrote Variable values and Connection extra contents to the audit log in cleartext when they were submitted through the bulk endpoints (PATCH /api/v2/variables and PATCH /api/v2/connections). The audit-log masking recognised only top-level request fields, and a bulk request nests its entities two levels below, so no masking was applied to them. Any authenticated user with audit-log read access -- who need not hold Variables or Connections read at all -- could recover those secrets verbatim, and the Connection extra copy is stored unencrypted in the log while the connection table encrypts it. The Airflow UI's Import Variables action posts to this endpoint, so an ordinary operator import wrote every secret in the file to the log. This is a different code path from CVE-2026-50204: that fix shipped in 3.3.0 and covers the single-entity endpoints 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 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 wrote Variable values and Connection extra contents to the audit log in cleartext when they were submitted through the bulk endpoints (PATCH /api/v2/variables and PATCH /api/v2/connections). The audit-log masking recognised only top-level request fields, and a bulk request nests its entities two levels below, so no masking was applied to them. Any authenticated user with audit-log read access -- who need not hold Variables or Connections read at all -- could recover those secrets verbatim, and the Connection extra copy is stored unencrypted in the log while the connection table encrypts it. The Airflow UI's Import Variables action posts to this endpoint, so an ordinary operator import wrote every secret in the file to the log. This is a different code path from CVE-2026-50204: that fix shipped in 3.3.0 and covers the single-entity endpoints 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.