The vulnerability arises from an unsafe pattern used in the example_xcom DAG for reading XCom values, which can be exploited when a UI user with XCom modification rights triggers a race condition that leads to arbitrary code execution on an Airflow worker. The flaw allows the user to inject and execute arbitrary Python code, resulting in a remote code execution condition. Because the attack requires a trusted UI account and the example DAGs are not intended for production use, the severity is considered low, but any system that adopts the same pattern is at risk.

Apache Software Foundation’s Airflow is the affected product. The issue appears only in DAGs that copy the example_xcom logic from the official documentation; it is not present in core Airflow releases. Users who have included the example DAG or otherwise implemented the same unsafe XCom access pattern could be affected. The Airflow 3.2.0 documentation has been updated with a safer version of the example, so upgrading to that or newer reduces the risk.

Exploitation requires a user who already has the ability to write to XComs through the Airflow UI, a privilege normally held by highly trusted individuals or processes. Because the CVSS score and EPSS are not published and the vulnerability is not listed in CISA’s KEV catalog, the overall exposure is low. An attacker would still need to insert malicious payload into an XCom and trigger the race condition to cause the worker to evaluate the payload, which is unlikely without the prerequisite UI access. Consequently, the risk is confined to environments where the example DAG is deployed or mirrored in production, and the exploitability is limited.