# OpenManus Prompt-Handler OS Command Injection via python_execute

- **Severity:** High
- **Signature ID:** `7b3f2c9e-5a41-4d8b-9f16-2c0d84e7a153`

## Summary

OpenManus is an open-source AI agent framework. It has an unpatched flaw where text an attacker feeds into its Prompt Handler gets passed to a Python execution tool without sanitization, letting that text run arbitrary operating-system commands. This detection catches the exploit actually being carried out, not just the presence of vulnerable code.

## 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.

## 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/

---
Source: https://www.netzilo.com/threats/openmanus-python-execute-os-injection