# SuperAGI Output Handler Eval RCE

- **Severity:** High
- **Signature ID:** `7c1e4b0a-3f2d-4a86-9b51-2d8e0f6ac417`
- **MITRE ATLAS:** AML.T0050 (Command and Scripting Interpreter), AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM05 (Improper Output Handling), ASI05 (Cascading Failures in Multi-Agent Systems), ASI06 (Goal and Instruction Manipulation)

## Summary

SuperAGI, an AI agent framework, feeds model or tool output straight into Python's eval() without checking it. An attacker who can influence that output (through a prompt injection or a malicious tool response) can make the agent run arbitrary system commands.

## How the attack works

An attacker plants malicious text in something the agent will read, such as a tool result or a document it summarizes, that looks like a normal instruction but is actually Python code. SuperAGI's output handler passes this text to eval(), which only executes expressions, so the payload has to use tricks like __import__('os').system(...), eval(compile(...)), exec(__import__(...)) or base64/marshal-encoded blobs to reach the operating system. When SuperAGI evaluates it, a Python interpreter is spawned with that inline code on its command line, and the attacker's command runs with the privileges of the agent process. The rule watches for exactly that: a Python -c command line combining an eval/exec call with an OS, network, decode, or introspection sink, or the telltale __import__('os') pattern.

## Why it matters

An attacker gets arbitrary code execution on the host running the AI agent, using whatever access and credentials that agent process has — potentially reading files, reaching internal networks, or pivoting further.

## What you can do

- Never pass raw model or tool output to eval() or exec(); use structured parsing (JSON, defined schemas) instead.
- Sandbox or containerize agent processes so a code-execution bug there can't reach the wider network or filesystem.
- Restrict what tools and data sources an agent can read from, especially anything an outside party can influence.
- Review agent logs for Python subprocesses launched with -c and unusual encoded or dotted-import payloads.

## Known benign look-alikes

- pip / legacy build backends invoking the setuptools setup.py shim ("python -c 'import setuptools, tokenize; ... exec(compile(...))'") -- suppressed by filter_pip_setuptools_shim.
- Security scanners and grep-like tools whose own argv contains "eval(" while searching a codebase for eval sinks -- suppressed by filter_static_analysis.
- Unit/integration tests and security regression fixtures that deliberately execute eval payloads under pytest/tox -- suppressed by filter_test_harness.
- Ansible/Salt/Chef/Puppet inline Python modules that embed base64-decoded payloads -- suppressed by filter_config_mgmt.
- Developer or CI one-liners such as "python -c \"import subprocess; subprocess.run(...)\""; these use a plain import statement and no eval/exec call, so they do not match.
- Pandas / SQLAlchemy "df.eval(...)" and "ast.literal_eval(...)" expressions -- excluded by the leading negated character class in sel_eval_call and by filter_literal_eval.

## References

- https://attack.mitre.org/techniques/T1059/006/
- https://cwe.mitre.org/data/definitions/95.html
- https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/

---
Source: https://www.netzilo.com/threats/superagi-output-handler-eval-rce