ToolUniverse Unauthenticated Sandbox Escape to Remote Code Execution

Technical Analysis

The executor in python_executor_tool.py attempts to block dangerous code by denylisting specific attribute names and calls, but it fails to block dunder attribute access reached via string-based lookups (e.g., getattr) or via already-permitted modules, allowing an attacker to traverse from any object's __class__ to __base__ and enumerate __subclasses__() to obtain live references to os/subprocess-capable classes. A caller-controlled parameter also lets the attacker widen the module import allow-list before the security inspection runs, further weakening the check. The entry point is the http_api_server.py and smcp_server.py servers, which bind to 0.0.0.0 with debug mode on and no authentication, so any network-reachable client can invoke the tool directly. Because the MCP/HTTP layer has no identity or access control, the tool-layer boundary between untrusted caller input and server-side code execution is completely absent, giving an attacker full RCE as the server process with no chaining or lateral movement required.

Affected Systems

ToolUniverse; protocols: MCP, HTTP

Detection Signatures

• Outbound requests to python_code_executor tool containing __class__, __base__, __subclasses__, __mro__, or getattr()-based dunder traversal patterns
• MCP/HTTP server logs showing unauthenticated requests to smcp_server.py or http_api_server.py endpoints
• Processes spawned from the ToolUniverse server as children (e.g., subprocess.Popen, os.system) shortly after python_code_executor invocations
• Server binding to 0.0.0.0 with Flask/Werkzeug debug mode enabled
• Requests that modify or widen an import allow-list parameter prior to code submission

Remediation Steps

1. 1

   Upgrade to ToolUniverse 1.3.0+

   Apply the patched version which adds bearer-token authentication, defaults binding to loopback, and hardens attribute-access checks.

2. 2

   Enforce authentication on all MCP/HTTP endpoints

   Require strong authentication (bearer tokens, mTLS) for any server exposing code-execution tools, and never rely on network obscurity.

3. 3

   Bind to loopback or firewall the service

   Do not bind agent tool servers to 0.0.0.0; restrict to localhost or internal networks with strict firewall rules until authenticated.

4. 4

   Replace denylist sandboxing with real isolation

   Run untrusted Python code in a properly isolated environment (gVisor, Firecracker microVM, container with dropped capabilities, seccomp/AppArmor) rather than attribute-name denylisting, which is provably bypassable.

5. 5

   Disable debug mode in production

   Ensure Flask/Werkzeug debug mode is off in any production-facing deployment, as it can itself provide code execution and information disclosure.

6. 6

   Audit and restrict import allow-list controls

   Remove caller-supplied ability to modify security-relevant configuration such as import allow-lists prior to sandbox inspection.