Summary
Heym's Agent custom Python tool can bypass its blacklist-based sandbox because permitted standard-library modules expose operating-system, process, and filesystem capabilities. An authenticated user who can create or edit a workflow may cause the backend to execute commands or perform file operations with the application's privileges.
Heym's Agent custom Python tool can bypass its blacklist-based sandbox because permitted standard-library modules expose operating-system, process, and filesystem capabilities. An authenticated user who can create or edit a workflow may cause the backend to execute commands or perform file operations with the application's privileges.
Affected context
The issue affects self-hosted Heym deployments that allow authenticated users to create or modify workflows containing Agent custom Python tools. Risk arises when the backend relies on blacklist-based import and code checks, then executes user-controlled Python with the application's operating-system privileges. Self-registration may increase reachability in some deployments, but triggering a portal workflow alone does not necessarily provide code control.
The issue affects self-hosted Heym deployments that allow authenticated users to create or modify workflows containing Agent custom Python tools. Risk arises when the backend relies on blacklist-based import and code checks, then executes user-controlled Python with the application's operating-system privileges. Self-registration may increase reachability in some deployments, but triggering a portal workflow alone does not necessarily provide code control.
Exploit preconditions
- Attack surface: Agent custom Python tool execution in the backend workflow system
- Required access: An authenticated account with permission to create or edit a workflow containing the tool
- Trigger point: Execution of the workflow by the backend Python runner
- Why exploitation is possible: Allowed standard-library modules expose operating-system, process, and filesystem functionality through public attributes that evade blacklist checks before the supplied code is executed
- Attack surface: Agent custom Python tool execution in the backend workflow system
- Required access: An authenticated account with permission to create or edit a workflow containing the tool
- Trigger point: Execution of the workflow by the backend Python runner
- Why exploitation is possible: Allowed standard-library modules expose operating-system, process, and filesystem functionality through public attributes that evade blacklist checks before the supplied code is executed
Why this happens
The underlying flaw is reliance on blacklist-based sandboxing for untrusted Python code. Import and code-validation checks evaluate selected names or patterns, but do not reliably constrain the capabilities reachable through permitted modules and their public attributes. The runner then passes user-influenced code to exec(), allowing the supplied program to access process, operating-system, and filesystem operations. This maps primarily to CWE-78: Improper Neutralization of Special Elements used in an OS Command, with related characteristics of CWE-94: Improper Control of Generation of Code and CWE-693: Protection Mechanism Failure.
The underlying flaw is reliance on blacklist-based sandboxing for untrusted Python code. Import and code-validation checks evaluate selected names or patterns, but do not reliably constrain the capabilities reachable through permitted modules and their public attributes. The runner then passes user-influenced code to exec(), allowing the supplied program to access process, operating-system, and filesystem operations. This maps primarily to CWE-78: Improper Neutralization of Special Elements used in an OS Command, with related characteristics of CWE-94: Improper Control of Generation of Code and CWE-693: Protection Mechanism Failure.
Potential impact
- An attacker could execute operating-system commands as the backend application user
- An attacker may read, create, modify, or delete files accessible to that account
- Application secrets, workflow data, or environment-held credentials could be exposed
- The backend service could be disrupted or altered
- Compromise could enable further movement depending on service permissions and network access
- An attacker could execute operating-system commands as the backend application user
- An attacker may read, create, modify, or delete files accessible to that account
- Application secrets, workflow data, or environment-held credentials could be exposed
- The backend service could be disrupted or altered
- Compromise could enable further movement depending on service permissions and network access
General mitigation guidance
Mitigation generally focuses on preventing untrusted workflow authors from executing general-purpose Python in the backend process.
Common defensive patterns include:
- Prefer narrowly scoped, declarative tools over arbitrary Python execution
- Run user-controlled code in a strongly isolated execution boundary rather than the application process
- Use allowlisted capabilities and APIs instead of blacklist-based import or syntax filtering
- Apply strict resource, filesystem, network, and subprocess restrictions to the execution environment
- Run workers with dedicated low-privilege identities and minimal access to secrets and host resources
- Enforce authorization and approval controls for workflow creation and tool modification
- Treat workflow definitions and tool code as untrusted input throughout their lifecycle
Mitigation generally focuses on preventing untrusted workflow authors from executing general-purpose Python in the backend process.
Common defensive patterns include:
- Prefer narrowly scoped, declarative tools over arbitrary Python execution
- Run user-controlled code in a strongly isolated execution boundary rather than the application process
- Use allowlisted capabilities and APIs instead of blacklist-based import or syntax filtering
- Apply strict resource, filesystem, network, and subprocess restrictions to the execution environment
- Run workers with dedicated low-privilege identities and minimal access to secrets and host resources
- Enforce authorization and approval controls for workflow creation and tool modification
- Treat workflow definitions and tool code as untrusted input throughout their lifecycle
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving
exec(), dynamic code generation, unrestricted Python tool runners, or blacklist-based sandbox checks - Code-review signals showing user-controlled workflow content reaching interpreters or process, filesystem, and subprocess APIs
- Policy rules that prohibit arbitrary code execution inside application services
- Runtime telemetry for unexpected child processes, filesystem changes, command interpreters, or outbound connections from workflow workers
- Access reviews for users who can create or edit workflows and custom tools
Automated code-review and software-composition tools may help identify dangerous execution patterns, but should be combined with architecture and runtime controls.
Organizations can look for:
- Static-analysis findings involving
exec(), dynamic code generation, unrestricted Python tool runners, or blacklist-based sandbox checks - Code-review signals showing user-controlled workflow content reaching interpreters or process, filesystem, and subprocess APIs
- Policy rules that prohibit arbitrary code execution inside application services
- Runtime telemetry for unexpected child processes, filesystem changes, command interpreters, or outbound connections from workflow workers
- Access reviews for users who can create or edit workflows and custom tools
Automated code-review and software-composition tools may help identify dangerous execution patterns, but should be combined with architecture and runtime controls.
