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.
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 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 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: 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.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: 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
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 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.
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: the Core API logout endpoint revokes only a session token presented as the token cookie. When a client logs out presenting its credential as an Authorization bearer header instead, the endpoint returns its normal logout response but revokes nothing, so the token remains valid until it expires. An attacker who already holds a copy of that token keeps the victim's access after the victim has logged out and believes the session ended; the default token lifetime is 24 hours and is configurable.
Affects API clients that authenticate with a bearer token rather than the browser session cookie. The attacker must already possess a copy of a valid token; obtaining one is outside the scope of this issue, and no privileges beyond the victim's own are gained.
Users of apache-airflow are recommended to upgrade to apache-airflow version 3.3.2 or later, which fixes the issue.
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.
When a request to the Airflow core API carries both a session cookie and an explicit Authorization: Bearer token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented.
Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable.
Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation.
Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.
When a request to the Airflow core API carries both a session cookie and an explicit Authorization: Bearer token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented.
Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable.
Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation.
Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.
When a request to the Airflow core API carries both a session cookie and an explicit Authorization: Bearer token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented.
Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable.
Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation.
Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.
Severity: moderate
Affected versions:
- Apache Airflow before 3.3.2
Description:
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.
Credit:
n0mi1k (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/71741 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-75158
Severity: low
Affected versions:
- Apache Airflow 3.0.0 before 3.3.2
Description:
Apache Airflow: the Core API logout endpoint revokes only a session token presented as the token cookie. When a client logs out presenting its credential as an Authorization bearer header instead, the endpoint returns its normal logout response but revokes nothing, so the token remains valid until it expires. An attacker who already holds a copy of that token keeps the victim's access after the victim has logged out and believes the session ended; the default token lifetime is 24 hours and is configurable.
Affects API clients that authenticate with a bearer token rather than the browser session cookie. The attacker must already possess a copy of a valid token; obtaining one is outside the scope of this issue, and no privileges beyond the victim's own are gained.
Users of apache-airflow are recommended to upgrade to apache-airflow version 3.3.2 or later, which fixes the issue.
Credit:
OpenSec Intelligence (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72649 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-86473
Severity: low
Affected versions:
- Apache Airflow 3.3.0 before 3.3.2
Description:
When a request to the Airflow core API carries both a session cookie and an explicit Authorization: Bearer token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented.
Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable.
Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation.
Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.
Credit:
Claude Security Scans (tool) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72225 https://github.com/apache/airflow/pull/72723 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-82355
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 Apache Kafka provider versions 1.15.0 before 2.0.0 resolve dotted-path strings found in a Kafka connection's extra field into Python callables via importstring, with no allowlist, and hand them to the confluent-kafka client which invokes them. Deployments that have enabled the Kafka event producer — dagruneventsenabled or taskinstanceeventsenabled, both disabled by default — build that client inside the scheduler process, so a user whose only privilege is editing Airflow connections gains arbitrary code execution in the control plane; the Airflow security model limits connection-configuration users to code execution on workers, not the scheduler. Deployments using Google Managed Kafka are not affected, because that code path overwrites any user-supplied oauthcb; plain brokers and Amazon MSK are exposed. Users are recommended to upgrade to apache-airflow-providers-apache-kafka 2.0.0 or later, which adds an allowlist configuration option for connection-string callbacks.
Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement — so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held.
Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain.
Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.
Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checks that the two describe the same subject. A user who holds any valid Airflow login of their own, together with another subject's Keycloak access or refresh token obtained out of band, can pair the two: Airflow then authorizes requests with the foreign token's privileges while the session identity, audit log and cache keys continue to name the attacker's own account. The refresh path re-issues an Airflow session token for the original identity carrying the foreign tokens, so the mismatched pairing survives across sessions.
Affects deployments running Airflow 3.3 or later with the Keycloak auth manager. Earlier versions carried the Keycloak tokens inside the signed session token, so the binding existed and was lost when they moved into separate cookies.
Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which binds the cookie-supplied tokens to the session identity.