apache-airflow-core 3.4.0rc1

Direct Vulnerabilities

Known vulnerabilities in the apache-airflow-core package. This does not include vulnerabilities belonging to this package’s dependencies.

Fix vulnerabilities automatically

Snyk's AI Trust Platform automatically finds the best upgrade path and integrates with your development workflows. Secure your code at zero cost.

Fix for free

Vulnerability	Vulnerable Version
C Deserialization of Untrusted Data Affected versions of this package are vulnerable to Deserialization of Untrusted Data via the scheduler's dependency evaluation path, which fully deserializes XCom values written by task code through `XComModel.deserialize_value`. The `XComDecoder` object hook invokes the Airflow serialization module with `full=True`, meaning any stored dict carrying a `__classname__` key is imported and instantiated inside the scheduler process. A DAG author who controls what a task writes to XCom can therefore cause arbitrary class instantiation in the scheduler, a privilege level the Airflow security model reserves for the Deployment Manager rather than DAG authors. Note: This is only exploitable in deployments where DAG authors are treated as less trusted than Deployment Managers, and only when the scheduler is evaluating a task dependency that reads a task-written XCom value. How to fix Deserialization of Untrusted Data? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[,3.4.0)
H Deserialization of Untrusted Data Affected versions of this package are vulnerable to Deserialization of Untrusted Data via the `_decode_next_kwargs` path in the scheduler's `check_awaiting_input_timeouts` sweep and the API server's task-instance serving route, where the stored `next_kwargs` payload is fully deserialized before the resulting value is checked to be a dictionary. Deserialization reconstructs nested objects of classes on the allow-list, including Airflow's own classes, and runs their constructors inside the scheduler or API server process before the dict check can reject the payload. A DAG author who controls a task's `next_kwargs` through the task execution API can therefore trigger constructor execution in the scheduler when the `awaiting_input` timeout sweep processes the task, and in the API server when the task instance is served to a worker using an older Execution API version. This is an incomplete fix for CVE-2026-67260, affecting only versions 3.3.0 and 3.3.x. How to fix Deserialization of Untrusted Data? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[3.3.0,3.4.0)
C Missing Authentication for Critical Function Affected versions of this package are vulnerable to Missing Authentication for Critical Function via `ExecuteCallback` workloads in CeleryExecutor, which ran deadline-alert callbacks without validating the workload's authentication token. An attacker with write access to the Celery broker can enqueue a forged `ExecuteCallback` message and execute arbitrary code on every CeleryExecutor worker, without requiring Airflow credentials. How to fix Missing Authentication for Critical Function? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[,3.4.0)
C Operation on a Resource after Expiration or Release Affected versions of this package are vulnerable to Operation on a Resource after Expiration or Release via the logout endpoint, which silently swallows any error that occurs during server-side token revocation and reports success regardless. When an auth manager (such as FAB or Keycloak) redirects logout to an external URL, server-side revocation is the only mechanism that invalidates the Airflow token. Revocation fails on database errors and, reliably, for tokens issued by an external identity provider accepted via `[api_auth] trusted_jwks_url` whose `jti` claim exceeds 32 characters - overflowing the `revoked_token.jti` column and raising a `DataError` on PostgreSQL and MySQL. An attacker who obtains a copy of a user's token before logout can continue using it against the Airflow API until the token naturally expires. How to fix Operation on a Resource after Expiration or Release? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[,3.4.0)
H Cleartext Storage of Sensitive Information Affected versions of this package are vulnerable to Cleartext Storage of Sensitive Information in the audit-log decorator (`airflow/api_fastapi/logging/decorators.py`), specifically in `_mask_connection_fields` and `_mask_variable_fields`, because the secrets masker matched only on configured sensitive key names rather than masking all values unconditionally. Connection `extra` field values stored under arbitrary key names and Variable values are written verbatim to the `Log.extra` column, allowing an authenticated low-privilege user with read access to the event-log or audit API to recover credentials they would not otherwise have access to. Note: This is only exploitable by an authenticated user with read access to the event-log / audit API. How to fix Cleartext Storage of Sensitive Information? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[,3.4.0)
H Insufficiently Protected Credentials Affected versions of this package are vulnerable to Insufficiently Protected Credentials via the connections API, which fails to mask the `config` extra field declared as sensitive by the apprise provider. Because the name-based masking logic only checks a fixed global list of secret field names and `config` is not on that list, a user with read-connections permission can retrieve notification-service credentials embedded in the `config` extra in cleartext. How to fix Insufficiently Protected Credentials? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[,3.4.0)
H Deserialization of Untrusted Data Affected versions of this package are vulnerable to Deserialization of Untrusted Data via the DAG run `conf` field, which did not reject reserved serialization keys (such as `__classname__` or `__type__`). A user permitted to trigger a DAG that uses a deadline alert with an asynchronous callback can pass a `conf` containing these reserved keys, which, once the deadline is missed, either crashes the scheduler repeatedly or causes the Triggerer to reconstruct arbitrary objects from the malicious `conf` data. How to fix Deserialization of Untrusted Data? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[3.2.0,3.4.0)
H Deserialization of Untrusted Data Affected versions of this package are vulnerable to Deserialization of Untrusted Data via the `_check_forbidden_xcom_keys` validator in the Task Execution API's `set_xcom` handler, which fails to inspect XCom values submitted as JSON string literals. The `_walk` helper recursively checks dict and list structures for reserved serialization keys (`__classname__`, `__type`, `__var`, etc.) but does not attempt to parse string values, so a DAG author's task can write an XCom whose value is a JSON-encoded string containing those reserved keys. When a user later retrieves that XCom through the API with `?deserialize=true`, the API server re-parses the string into a dict and instantiates classes from the `airflow.*` namespace with attacker-controlled arguments. This is an incomplete fix for CVE-2026-59242. How to fix Deserialization of Untrusted Data? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[3.0.0,3.4.0)
M Incorrect Authorization Affected versions of this package are vulnerable to Incorrect Authorization via the asynchronous connection test endpoint (`enqueue_connection_test`) when `commit_on_success` is set. The permission check occurs at enqueue time, granting only `POST` (create) authorization when the connection ID does not yet exist, but the `commit_to_connection_table` call at completion writes the tested connection unconditionally, including overwriting a connection created by another request in the interim. A user with create-but-not-edit permission on connections can therefore overwrite a connection they are not authorized to modify. Note: This is only exploitable if the non-default `[core] test_connection` setting is explicitly enabled. How to fix Incorrect Authorization? Upgrade `apache-airflow-core` to version 3.4.0 or higher.	[3.3.0,3.4.0)

Vulnerability

Vulnerable Version

Deserialization of Untrusted Data

Affected versions of this package are vulnerable to Deserialization of Untrusted Data via the scheduler's dependency evaluation path, which fully deserializes XCom values written by task code through XComModel.deserialize_value. The XComDecoder object hook invokes the Airflow serialization module with full=True, meaning any stored dict carrying a __classname__ key is imported and instantiated inside the scheduler process. A DAG author who controls what a task writes to XCom can therefore cause arbitrary class instantiation in the scheduler, a privilege level the Airflow security model reserves for the Deployment Manager rather than DAG authors.

Note: This is only exploitable in deployments where DAG authors are treated as less trusted than Deployment Managers, and only when the scheduler is evaluating a task dependency that reads a task-written XCom value.

How to fix Deserialization of Untrusted Data?