Apache Airflow's serialization layer reconstructed exception nodes by calling importstring() on a class name taken from the serialized blob and instantiating it with arguments from the same blob, with no restriction on what could be imported. An operator's executorconfig reaches that branch, so a Dag author could place a value there that causes an arbitrary callable to be imported and invoked -- for example subprocess.checkoutput, or builtins.eval on the builtins-prefixed variant. The code runs in the Scheduler, which reconstructs serialized Dags in its normal loop with no request involved, and in the API server, on any authenticated read of the Dag such as GET /api/v2/dags/{dagid}/details. Both are components the Airflow security model states must never execute Dag-author code, and both hold the metadata database credentials and the JWT signing secret. No non-default configuration is required. This is a different sink from CVE-2026-33264, which covered only the trigger branch of the same deserializer: deployments that upgraded in response to that advisory are still affected through the exception branch and must upgrade again. Users are advised to upgrade to apache-airflow 3.3.1 or later, which restricts the imported class to a subclass of BaseException.
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'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.
Apache Airflow 3.3.0 moved human-in-the-loop tasks from the triggerer to a new awaitinginput task state swept by the scheduler. That sweep deserializes the task instance's nextkwargs without an allow-list, so a Dag author — who controls that value through the task execution API — can cause an arbitrary module import and object instantiation inside the scheduler process, or terminate the scheduler job. No non-default configuration is required: the sweep runs unconditionally every 15 seconds, and the default alloweddeserializationclasses setting does not cover this code path. Versions before 3.3.0 are not affected, because human-in-the-loop tasks deferred onto the triggerer instead. This is a different code path from CVE-2026-58076, which covers the same unguarded exception-node deserialization reached elsewhere — deployments that applied that fix must upgrade for this issue as well. 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.
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.
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.
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.
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.
In Apache Airflow, prior to version 2.4.1, deactivating a user wouldn't prevent an already authenticated user from being able to continue using the UI or API.
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Apache Airflow Hive Provider, Apache Airflow allows an attacker to execute arbtrary commands in the task execution context, without write access to DAG files. This issue affects Hive Provider versions prior to 4.1.0. It also impacts any Apache Airflow versions prior to 2.3.0 in case HIve Provider is installed (Hive Provider 4.1.0 can only be installed for Airflow 2.3.0+). Note that you need to manually install the HIve Provider version 4.1.0 in order to get rid of the vulnerability on top of Airflow 2.3.0+ version that has lower version of the Hive Provider installed).
In Apache Airflow 2.3.0 through 2.3.4, part of a url was unnecessarily formatted, allowing for possible information extraction.
A vulnerability in Example Dags of Apache Airflow allows an attacker with UI access who can trigger DAGs, to execute arbitrary commands via manually provided runid parameter. This issue affects Apache Airflow Apache Airflow versions prior to 2.4.0.
A remote code/command injection vulnerability was discovered in one of the example DAGs shipped with Airflow.
UI / API User with asset materialize permission could trigger dags they had no access to. Users are advised to migrate to Airflow version 3.2.0 that fixes the issue.
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.
An example of BashOperator in Airflow documentation suggested a way of passing dagrun.conf in the way that could cause unsanitized user input to be used to escalate privileges of UI user to allow execute code on worker. Users should review if any of their own DAGs have adopted this incorrect advice.
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.
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.
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.
Apache Airflow versions 3.1.0 through 3.1.7 missing authorization vulnerability in the Execution API's Human-in-the-Loop (HITL) endpoints that allows any authenticated task instance to read, approve, or reject HITL workflows belonging to any other task instance.
Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Apache Airflow versions 3.1.0 through 3.1.7 session token (token) in cookies is set to path=/ regardless of the configured [webserver] baseurl or [api] baseurl. This allows any application co-hosted under the same domain to capture valid Airflow session tokens from HTTP request headers, allowing full session takeover without attacking Airflow itself.
Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
Apache Airflow versions 3.0.0 through 3.1.7 FastAPI DagVersion listing API does not apply per-DAG authorization filtering when the request is made with dagid set to "~" (wildcard for all DAGs). As a result, version metadata of DAGs that the requester is not authorized to access is returned.
Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue.
DAG Author (who already has quite a lot of permissions) could manipulate database of Airflow 2 in the way to execute arbitrary code in the web-server context, which they should normally not be able to do, leading to potentially remote code execution in the context of web-server (server-side) as a result of a user viewing historical task information.
The functionality responsible for that (log template history) has been disabled by default in 2.11.1 and users should upgrade to Airflow 3 if they want to continue to use log template history. They can also manually modify historical log file names if they want to see historical logs that were generated before the last log template change.
In Apache Airflow versions before 3.1.6, and 2.11.1 the proxies and proxy fields within a Connection may include proxy URLs containing embedded authentication information. These fields were not treated as sensitive by default and therefore were not automatically masked in log output. As a result, when such connections are rendered or printed to logs, proxy credentials embedded in these fields could be exposed.
Users are recommended to upgrade to 3.1.6 or later for Airflow 3, and 2.11.1 or later for Airflow 2 which fixes this issue
In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] maxtemplatedfieldlength, sensitive values could be exposed in cleartext in the Rendered Templates UI. This occurred because serialization of those fields used a secrets masker instance that did not include user-registered masksecret() patterns, so secrets were not reliably masked before truncation and display.
Users are recommended to upgrade to 3.1.6 or later, which fixes this issue
Insertion of Sensitive Information into Log File vulnerability in Apache Airflow Celery provider, Apache Airflow.
Sensitive information logged as clear text when rediss, amqp, rpc protocols are used as Celery result backend Note: the vulnerability is about the information exposed in the logs not about accessing the logs.
This issue affects Apache Airflow Celery provider: from 3.3.0 through 3.4.0; Apache Airflow: from 1.10.0 through 2.6.3.
Users are recommended to upgrade Airflow Celery provider to version 3.4.1 and Apache Airlfow to version 2.7.0 which fixes the issue.
Example DAG: exampleinleteventextra.py shipped with Apache Airflow version 2.10.0 has a vulnerability that allows an authenticated attacker with only DAG trigger permission to execute arbitrary commands. If you used that example as the base of your DAGs - please review if you have not copied the dangerous example; see https://github.com/apache/airflow/pull/41873 for more information. We recommend against exposing the example DAGs in your deployment. If you must expose the example DAGs, upgrade Airflow to version 2.10.1 or later.
Apache Airflow versions before 2.10.1 have a vulnerability that allows DAG authors to add local settings to the DAG folder and get it executed by the scheduler, where the scheduler is not supposed to execute code submitted by the DAG author. Users are advised to upgrade to version 2.10.1 or later, which has fixed the vulnerability.