OpenManus Prompt-Handler OS Command Injection via python_execute

How the attack works

An attacker submits crafted input through OpenManus's Prompt Handler instead of a normal task description. That input reaches the python_execute tool and is run as Python code. Because the input isn't sanitized, the attacker embeds an OS command-execution call (such as os.system, subprocess with shell=True, or pty.spawn) inside it. The rule looks for a single command line that combines Python's inline-execution flag, one of these OS exec primitives, and a real attack payload such as a reverse shell, a download-piped-to-shell command, credential file access, encoded PowerShell, or a destructive delete. A related check also fires when the command line references the vulnerable OpenManus component together with an OS exec primitive.

Netzilo detection

Why it matters

An attacker gets arbitrary command execution on the host running OpenManus, which can lead to full system compromise, credential theft, lateral movement, or destruction of data — with the AI agent itself as the entry point.

What you can do

• →Restrict or remove OS command-execution capability from the python_execute tool if your OpenManus deployment doesn't need it.
• →Run OpenManus's Python execution tool inside a sandbox or container with no access to sensitive files or the wider network.
• →Treat this detection as report-only initially and review flagged events manually — deliberate debugging, red-team testing, and CI scripts that shell out from Python can look identical to the real attack.
• →Restrict who can submit input to the Prompt Handler and log/monitor that input separately from the resulting execute_process activity.

Known benign look-alikes

• Developers or SREs running a deliberate one-liner such as `python -c "import os; os.system('whoami')"` while debugging the OpenManus sandbox or verifying tool permissions.
• Security researchers and red-team operators reproducing the public OpenManus proof-of-concept on a lab host; the command line is identical to the real exploit and cannot be distinguished by content alone.
• CI provisioning steps that shell out from Python with `subprocess.run(..., shell=True)` to fetch and pipe an installer script; mitigated only partially, since the download-pipe-to-shell payload marker is intentionally retained.
• Static-analysis and linting runs whose arguments quote the vulnerable code pattern (semgrep/bandit/codeql rule bodies, `python -m bandit`); suppressed by filter_static_analysis.
• Grep/ripgrep/findstr searches through the OpenManus source tree where the search expression contains `os.system(` or `shell=True`; suppressed by filter_search_tool, which only matches when the executable itself is a search utility.
• Documentation generators, snippet renderers, or automation templates that still carry unsubstituted placeholders such as `<your-command>`; suppressed by filter_placeholder.

References

• https://github.com/mannaandpoem/OpenManus
• https://owasp.org/Top10/A03_2021-Injection/
• https://attack.mitre.org/techniques/T1059/006/