Apache Airflow vulnerabilities

In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] max_templated_field_length, 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 mask_secret() 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.

A bug in `BaseSerialization.deserialize()` allowed unrestricted `import_string()` 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.

Apache Airflow documentation contained a `BashOperator` code example without proper quoting, allowing shell metacharacter injection via the `conf` field in the DAG trigger API. An authenticated user with `Dag.can_trigger` permission could execute arbitrary commands on the worker.

In Apache Airflow, the asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site. In 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 `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected. Users are advised to upgrade to apache-airflow 3.3.1 or later.

In Apache Airflow, the 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 submitted through bulk endpoints (`PATCH /api/v2/variables` and `PATCH /api/v2/connections`). The audit-log masking only recognized top-level request fields, and a bulk request nests entities two levels below, so no masking was applied. Any authenticated user with audit-log read access (not necessarily holding Variables or Connections read permissions) could recover those secrets verbatim, and the Connection `extra` copy is stored unencrypted in the log while the connection table encrypts it.

Apache Airflow's Backfill API authorized a request against a Dag id supplied by the caller whenever the `backfill_id` 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.

In Apache Airflow, the 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. In multi-team mode an authenticated user of one team could resolve another team's Connection and authenticate outward with that team's credentials.

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 `allowed_deserialization_classes` allow-list, so tightening that setting does not help. A Dag author — who controls a task instance's `next_kwargs` through the task execution API — can therefore cause an arbitrary module to be imported inside the scheduler process, when the scheduler's `awaiting_input` 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 has a vulnerability in the human-in-the-loop task handling, where deserialization of next_kwargs without an allow-list allows a DAG author to import arbitrary modules and instantiate objects in the scheduler process or terminate the scheduler job. Upgrade to 3.3.1 or later is required.

Apache Airflow's Config API did not mask team-scoped sensitive configuration values in multi-team deployments. When an administrator has enabled multi-team mode and exposed the Config API, an authenticated Viewer holding only configuration-read access — with no prior access to the secret — could read a team-scoped Celery broker URL, including its embedded credentials, in cleartext, while the equivalent global option was correctly masked. The secrets masker matched only base section and option names and did not normalize team-prefixed sections before the sensitivity check (CWE-200). This is a distinct masker bypass from CVE-2026-48828 and CVE-2026-48892: deployments that upgraded to apache-airflow 3.3.0 to address those issues remain affected by this team-scoped variant. Users are advised to upgrade to apache-airflow 3.3.1 or later, which normalizes team-scoped sections before masking.

Apache Airflow's secrets masker did not mask `var.json` Variable values whose value is a dict in the Rendered Templates UI — the dict value failed an `isinstance(str)` guard — so a secret stored as a JSON Variable and referenced in a template via `var.json` was displayed in cleartext to any user with access to that task's Rendered Templates view. Users are advised to upgrade to apache-airflow 3.3.1 or later, which masks nested Variable values regardless of type.

In Apache Airflow, the XCom `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` endpoint passed a string-literal payload through `BaseXCom.deserialize_value` without the `_check_forbidden_xcom_keys` 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 serialization layer reconstructs exception nodes by calling `import_string()` on a class name from the serialized blob and instantiating it with arguments from the same blob, with no restriction on what can be imported. A Dag author can place a value in `executor_config` that causes an arbitrary callable to be imported and invoked, e.g., `subprocess.check_output` or `builtins.eval`. The code runs in the Scheduler and API server, which per Airflow's security model must never execute Dag-author code.

In Apache Airflow, the 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.

In Apache Airflow before 3.3.0, the REST API task-instance detail and list endpoints returned a deferred task's trigger kwargs without masking. When a deferred operator passed a secret (for example a provider API key) into its trigger, any authenticated user with DAG-scoped task-instance read access for that DAG could read that secret in clear text while the task was deferred.

Before Apache Airflow 3.3.0, a user authorized to read one DAG could disclose the source code of other DAGs co-located in the same source file. The `GET /api/v2/dagSources/{dag_id}` endpoint and the equivalent UI view returned the entire source file without redacting unauthorized DAGs, bypassing per-DAG read authorization.

A vulnerability in Apache Airflow exposed per-key secrets-backend overrides (environment variables) as config options that were not masked. An authenticated user with Config read permission could retrieve plaintext secrets-backend credentials (e.g., role_id, secret_id) from the Config API.

A bug in Apache Airflow's `/ui/dependencies` scheduling graph endpoint leaks Dag IDs through the `dep.source` and `dep.target` fields of trigger and sensor dependency entries. An authenticated UI user with read permission on some Dags can enumerate identifiers of other Dags they are not authorized to read. This is a residual gap in the fix for CVE-2026-28563, which filtered the top-level Dag key but not the trigger/sensor dependency fields.

A vulnerability in the Apache Airflow Bulk Variables API causes the redactor to not receive the variable key, so the `should_hide_value_for_key` check (triggered by secret-suffixed key names like `_password`, `_token`, `_secret`) does not apply to JSON-decodable variable values. An authenticated user with bulk Variable read permission can retrieve plaintext values from JSON variables whose key would otherwise trigger redaction.

A vulnerability in Apache Airflow's Google provider operators `GCSToSFTPOperator` and `GCSTimeSpanFileTransformOperator` allows writing files outside the intended destination directory. An attacker with write access to the source GCS bucket can create an object with `..` segments in its name, leading to overwrite of arbitrary files on the SFTP server or the worker host.

A bug in Apache Airflow's KubernetesExecutor caused JWT tokens used by worker pods to authenticate against the Execution API to be passed as command-line arguments visible in the pod spec. An authenticated user with read-only Kubernetes access (e.g., `pods/get`) could harvest the JWT from `kubectl describe pod` output and call state-mutating Execution API endpoints.

In Apache Airflow, the EmailOperator and `airflow.utils.email` helpers establish SMTP STARTTLS connections without verifying the remote certificate when `smtp_starttls=True` and `smtp_ssl=False` are used. An attacker in a MITM position can present a self-signed certificate and capture SMTP credentials and message contents.

A bug in Apache Airflow's logout handling (FabAuthManager and KeycloakAuthManager) leaves previously-issued JWT tokens valid after logout, allowing an attacker to continue making authenticated API calls.

Apache Airflow before version 3.2.2 has a vulnerability in the GET /api/v2/eventLogs/{event_log_id} endpoint, which fetches audit log rows directly by numeric ID without per-Dag scoping. An authenticated user with audit log read permission for one Dag can read entries for other Dags by guessing or enumerating IDs.

In Apache Airflow, exploitation requires an already authenticated Airflow worker with a valid Log-server JWT for at least one Dag. The Log server authorized JWT tokens against Dag IDs by applying Python's `str.lstrip()` to the requested path segment when verifying the JWT's `sub` claim. `str.lstrip()` strips any character from a set, not a prefix, so a JWT for a Dag named `dag_a` would authorize log access to any other Dag whose name began with any subset of characters `{d, a, g, _}`. An authenticated worker could enumerate and read worker logs of other Dags, leaking task output and error traces beyond the per-Dag isolation boundary.

In Apache Airflow, a vulnerability exists in the scheduler-side deadline-reference decoder (`SerializedCustomReference.deserialize_reference`) that imports and executes arbitrary class paths from DAG-author-controlled serialized state without an allowlist. A DAG author whose code reaches the scheduler can embed a custom `DeadlineReference` pointing to an attacker-controlled module, causing the scheduler to import and instantiate the class with a live SQLAlchemy session.

In Apache Airflow, rendered template field handling caused bypass of nested sensitive key masking (e.g., password, token) when the field length exceeded the limit. An authenticated user with read permission could obtain plaintext secret values.

A vulnerability in Apache Airflow's XCom PATCH endpoint allowed authenticated users with XCom write permission to set entries under reserved key names (e.g. return_value), which combined with accepting serialized payloads treated as code by the triggerer's deserializer enabled remote code execution (RCE) on the triggerer. This is a fix-bypass of CVE-2026-33858, which added FORBIDDEN_XCOM_KEYS validation only on the POST path, not the PATCH path.

In Apache Airflow, the Variable response masker bypassed masking of nested sensitive keys (e.g., password, token) when the nesting depth exceeded the recursion limit. An authenticated user with read permission could obtain plaintext secret values.

A bug in Apache Airflow's bulk Task Instances API (PATCH/DELETE /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances) caused authorization to be evaluated against the dag_id from the URL path while operating on dag_id/dag_run_id from request-body entity fields. An authenticated 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. Affects deployments relying on per-Dag edit-scope isolation. Patched in apache-airflow 3.2.2.

Apache Airflow before version 3.2.2 has a vulnerability in `JWTRefreshMiddleware` where the JWT cookie lacks the `Secure` flag. In deployments behind an HTTPS-terminating proxy, an attacker on the network (Wi-Fi MITM) can capture the cookie and replay it against the authenticated API.

Apache Airflow before version 3.2.2 has a vulnerability in the partitioned_dag_runs endpoints in the UI, which enforce only asset-level access control, not per-Dag authorization. An authenticated user with global Asset:read permission can enumerate partition run state, schedule configuration, and asset wiring for Dags they are not authorized to read.

The structure_data endpoint in the Airflow UI returned external dependency graph nodes for linked DAGs without checking whether the caller had read permission on those linked DAGs. An authenticated UI/API user authorized for one DAG could enumerate linked DAG IDs and dependency metadata for other DAGs they were not authorized to read.

A bug in the login redirect route in Apache Airflow allowed authenticated users to craft URLs that bypassed the `is_safe_url` check, enabling redirection from a trusted Airflow domain to an attacker-controlled origin.

A DAG author can use symlinks or `..` sequences in task IDs to read or overwrite arbitrary files outside the configured log folder if the worker log folder is shared with the API server.

A bug in the GET `/api/v2/connections/{connection_id}` REST API endpoint in Apache Airflow allows an authenticated user with Connection-read permission to retrieve secrets stored in a Connection's `extra` JSON blob under field names not in the redaction allowlist. Affects deployments storing credentials in `extra` blobs and granting Connection-read access to multiple users.

Since version 5.2.0, when using deferrable mode with a Kubernetes configuration file for authentication, the Airflow worker serializes this file as a dictionary and stores it in metadata without encryption. In versions 2.3.0-2.6.0, the dictionary is also logged as plain text in the triggerer service. This allows anyone with access to metadata or logs to obtain the configuration file and access the Kubernetes cluster.

The session fixation vulnerability allowed authenticated users to continue accessing the Airflow webserver even after their password was reset by the admin, until the user's session expired. The fix implemented invalidates existing user sessions when the password is reset, when using the database session backend.

Apache Airflow, in versions prior to 2.7.0, contains a vulnerability that can be exploited by an authenticated user with Connection edit privileges. This allows access to connection information and the exploitation of the test connection feature, potentially leading to a denial of service (DoS) condition on the server.

A vulnerability in Apache Airflow allows authenticated users to bypass some restrictions, enabling code execution in the webserver context and access to certain DAGs that the user normally cannot access. The 'Run Task' feature has been deemed dangerous and removed in version 2.6.0.

Apache Airflow, versions before 2.6.3, has a vulnerability where an authenticated user can use crafted input to make the current request hang.

Apache Airflow, versions before 2.6.3, is affected by a vulnerability that allows unauthorized read access to a DAG through the URL.

In Apache Airflow, there is a vulnerability that may expose potentially sensitive values to users in certain situations. This issue affects versions from 2.5.0 before 2.6.2.