ES2604-0e3749e8 - Improper Isolation of Executable Logic in AI/ML Workflow Definitions

[stevechristeycoley]

Submission File: ES2604-0e3749e8-new-improper-isolation-executable-logic-ai-ml-workflow-definitions.txt

ID: ES2604-0e3749e8

SUBMISSION DATE: 2026-04-02 04:50:26

NAME: Improper Isolation of Executable Logic in AI/ML Workflow Definitions

DESCRIPTION:

AI/ML workflow orchestration platforms let users build pipelines by
connecting nodes in a visual interface. Each node can contain executable
logic (Python code, shell commands, API calls). The complete workflow is
serialized as a "flow definition," typically stored as JSON or YAML on the
server.The weakness occurs when a platform exposes an endpoint that accepts
externally supplied flow definitions and executes the embedded code without
enforcing a trust boundary between server-authored definitions and
attacker-controlled input. Because executing code within flow definitions
is the platform's core functionality, this is architecturally distinct from
traditional code injection.

Why this should concern developers:

In conventional code injection (CWE-94), user input unexpectedly reaches an
eval() or exec() call due to missing sanitization. The standard fix is to
sanitize input or avoid dynamic evaluation. In AI/ML pipeline platforms,
this advice does not apply. The platform must execute code in flow
definitions to function. The exec() call is not a mistake; it is the
mechanism by which flows run. The weakness is not that untrusted data
reaches a code execution function. It is that the platform fails to
distinguish between flow definitions authored by trusted users (stored
server-side) and definitions supplied by anonymous external parties through
public-facing endpoints.
Developers building features like "public flows" or "shared templates" may
not recognize that exposing a flow execution endpoint to unauthenticated
users is equivalent to offering unauthenticated remote code execution. The
flow definition is both data and code simultaneously, and the trust model
must account for this.

Technical impact:

Exploitation results in unauthenticated remote code execution. A single
HTTP POST with crafted JSON containing malicious Python in a flow node
definition achieves immediate RCE. An attacker can then harvest credentials
from environment variables and .env files, access connected databases and
cloud services, exfiltrate API keys and model artifacts, pivot to internal
networks, and compromise downstream systems. No authentication, user
interaction, or prior target knowledge is required beyond the endpoint URL.

Subtleties and variations:

1. The surface is not limited to one endpoint. In one real-world case
   (CVE-2026-33017 and CVE-2025-3248 in the same codebase), two separate
   endpoints exposed the same exec() path through different API routes. Fixing
   one while leaving the pattern intact allowed the second to persist. The
   root cause is the design pattern, not any individual endpoint.
2. The "public flow" feature creates inherent tension. The endpoint must be
   unauthenticated because its purpose is to serve flows to anonymous users.
   Adding auth breaks the feature. The correct fix is ensuring public
   endpoints only execute stored server-side flow logic and never accept
   externally supplied definitions with executable content. This requires
   separating the data plane (flow parameters) from the code plane (executable
   node logic) at the architecture level.
3. WAFs are largely ineffective. The payload is embedded within
   legitimate-looking JSON matching the expected schema. The code appears in a
   field where code is normally expected. Signature-based detection cannot
   distinguish legitimate definitions from weaponized ones without
   understanding the trust context of the request source.
4. The weakness extends beyond Python exec(). Any platform serializing
   executable logic into transferable definitions and processing them from
   mixed-trust sources exhibits this pattern: visual AI agent builders,
   low-code automation platforms, and pipeline tools supporting custom code
   nodes.
5. Exploitation occurs extremely rapidly after disclosure. For
   CVE-2026-33017, attackers built working exploits from the advisory alone
   within 20 hours, with no public PoC. The payload is a standard HTTP POST
   with JSON, requiring no specialized tooling.