EUVD-2026-57312
GHSA-fcmm-42r9-mmmm
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Network-reachable REST API requires authenticated low-privilege user with XCom write-and-read access; primary impact is credential confidentiality via Connection class instantiation, with limited integrity exposure and no availability impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4Blast Radius
ecosystem impact- 12 pypi packages depend on apache-airflow (1 direct, 11 indirect)
Ecosystem-wide dependent count for version 3.3.1.
DescriptionCVE.org
Apache Airflow's 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.
Articles & Coverage 1
AnalysisAI
Unsafe deserialization in Apache Airflow's XCom REST API allows an authenticated user with XCom write-and-read access to instantiate arbitrary airflow.* classes on the API server by smuggling reserved serialization keys inside JSON string literals. The _check_forbidden_xcom_keys guard inspected dict, list, and tuple types but did not attempt to JSON-decode str values, so a payload like json.dumps({"__classname__": "airflow.sdk.definitions.connection.Connection"}) passed the write-time check and was later reconstructed into a live Python object when read back via ?deserialize=true. No public exploit has been identified at time of analysis; vendor-released patch is available in apache-airflow 3.3.1.
Technical ContextAI
Apache Airflow's XCom (Cross-Communication) subsystem enables task instances within directed acyclic graphs to share data across runs. The v2 REST API exposes XCom entries at GET /api/v2/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/xcomEntries/{key} and supports a ?deserialize=true query parameter that passes stored values through BaseXCom.deserialize_value. This deserializer uses reserved dict keys - specifically __classname__ and __type__ - to reconstruct named Python classes, a mechanism intentionally scoped to the airflow.* namespace as a controlled object-graph reconstruction feature. The _check_forbidden_xcom_keys function was introduced to prevent writes containing these reserved keys, using an internal _walk function that recursively descended into dict, list, and tuple nodes. The root cause (CWE-502: Deserialization of Untrusted Data) stems from an inconsistency between the write-time validation path and the read-time deserialization path: _walk did not attempt to JSON-decode string values, so a payload submitted as json.dumps({"__classname__": ...}) stored a string, bypassed _walk, and was silently re-parsed into a dict containing the reserved key on the deserialization read path. The fix in PR #69378 adds a str branch to _walk that calls json.loads and recurses into the decoded structure before accepting the write. CPE cpe:2.3:a:apache_software_foundation:apache_airflow:*:*:*:*:*:*:*:* covers all versions without a lower bound.
RemediationAI
Upgrade to apache-airflow 3.3.1 or later, which incorporates the fix from PR #69378 and rejects reserved XCom serialization keys submitted as JSON string literals at write time (HTTP 422 returned). Full advisory details are at https://lists.apache.org/thread/dm0520yhh4mn7qknyoh45r2w6c5qg2mg. If an immediate upgrade is blocked, apply a network-layer or API gateway rule to reject requests to GET .../xcomEntries/{key}?deserialize=true from all but explicitly trusted service accounts; note this will break any workflow that legitimately relies on XCom deserialization and requires a controlled re-enable after upgrade. As a secondary compensating control, audit and minimize the set of accounts holding combined XCom write-and-read API permissions - this reduces the exploitable population with minimal operational disruption. Operators should also scan existing XCom entries in the database for string values that JSON-decode to dicts or lists containing __classname__ or __type__ keys, which would indicate prior exploitation attempts.
More in Apache Airflow
View allRemote code execution in Apache Airflow before 3.3.0 lets a DAG author embed a malicious trigger whose attacker-controll
Unsafe deserialization in Apache Airflow 3.3.0's Task SDK allows an authenticated DAG author to cause arbitrary module i
Unsafe deserialization in Apache Airflow 3.0.0 through 3.3.0 allows any DAG author to achieve arbitrary code execution i
Remote code execution in Apache Airflow 3.1.x allows authenticated DAG Authors to execute arbitrary code in the webserve
Command injection in Apache Airflow's BashOperator documentation example allows authenticated attackers to escalate priv
Unsafe XCom templating in Apache Airflow's documented example DAG (`example_xcom.py`) allowed an authenticated UI user w
CVE-2026-30911 is a security vulnerability (CVSS 8.1) that allows any authenticated task instance. High severity vulnera
Authorization bypass in Apache Airflow's Backfill API (all versions prior to 3.3.1) allows any authenticated user holdin
Information disclosure in Apache Airflow 3.0.0 through 3.1.x stems from incomplete secret masking and under-documented w
Apache Airflow 3.0.0 through 3.1.x exposes JWT authentication tokens in application logs, allowing any authenticated UI
CVE-2026-28779 is a security vulnerability (CVSS 7.5) that allows any application co-hosted under the same domain. High
Apache Airflow before 3.2.0 exposes SQL exception stack traces through API responses despite api/expose_stack_traces=fal
Same weakness CWE-502 – Deserialization of Untrusted Data
View allSame technique Deserialization
View allShare
External POC / Exploit Code
Leaving vuln.today