Summary
A critical code-injection vulnerability in camel-ai CAMEL allows model-produced Python code to run through the CodeExecutionToolkit's SubprocessInterpreter without an approval boundary. If an attacker can influence model output or otherwise cause the toolkit to process untrusted instructions, arbitrary commands may execute with the privileges of the hosting process.
Affected context
The issue affects CAMEL releases 0.2.91a1, 0.2.91a2, and 0.2.91a3 when the CodeExecutionToolkit is enabled and uses SubprocessInterpreter to execute Python code generated by a model. Risk depends on whether untrusted users, external content, or manipulated prompts can influence the generated code and whether an approval or policy-control layer exists before execution.
Exploit preconditions
- Attack surface: The CAMEL CodeExecutionToolkit and its SubprocessInterpreter execution path
- Required access: The ability to influence prompts, model context, tool inputs, or other content that affects generated Python code
- Trigger point: Model-produced code is submitted to the subprocess interpreter
- Why exploitation is possible: The execution path lacks an approval boundary that independently verifies or authorizes generated code before it runs
Why this happens
The underlying flaw is the direct treatment of model-generated content as executable Python without an independent authorization decision. This creates a code-injection condition mapped to CWE-94: Improper Control of Generation of Code ('Code Injection'), because data produced from an insufficiently trusted source is passed into an execution mechanism without adequate policy enforcement, validation, or isolation.
Potential impact
- An attacker may execute arbitrary Python or operating-system commands
- The hosting process could be compromised with its available privileges
- Sensitive files, credentials, or environment data could be exposed
- The system could modify application data or make unauthorized network requests
- A compromised runtime could be used for lateral movement or service disruption
General mitigation guidance
Mitigation generally focuses on preventing model output from becoming executable by default and placing an explicit authorization boundary before any code execution.
Common defensive patterns include:
- Disable code execution capabilities unless they are strictly required
- Require explicit, human-reviewed or policy-approved authorization before execution
- Prefer fixed, allowlisted operations and typed tools over arbitrary Python execution
- Treat prompts, retrieved content, tool results, and model output as untrusted inputs
- Run unavoidable execution in strongly isolated, ephemeral sandboxes with minimal privileges
- Restrict filesystem, network, process, and secret access for the execution environment
- Apply resource limits, audit logging, and default-deny security policies
How teams detect issues like this
Organizations can look for code paths that pass model responses, prompt-derived strings, or tool arguments into Python execution or subprocess APIs. Static analysis and code review should flag uses of exec, eval, dynamic script generation, shell invocation, and interpreter wrappers that lack an independent approval or allowlist check.
Runtime monitoring can alert on unexpected child processes, outbound connections, filesystem access, or command execution initiated by agent workers. CI policies may require documented authorization, sandboxing, and least-privilege controls for any feature that executes generated code; automated review tools can help identify these patterns.
