Description

ToolUniverse ran caller-supplied Python inside a sandbox that could be escaped, on a server that required no authentication. The executor behind the python_code_executor tool, in python_executor_tool.py, inspected the submitted source for a denied list of attribute names and calls but left the attribute-lookup builtins available and did not stop a dunder attribute reached through a string lookup or through a module already permitted, so a caller could walk from a literal's class to its base and enumerate subclasses to obtain a reference to the process and subprocess modules. A per-call argument also let the caller widen the import allow-list before the inspection ran. The HTTP and MCP servers in http_api_server.py and smcp_server.py bound to every interface with debugging enabled and no authentication, so any caller able to reach the port executed code as the server process. Version 1.3.0 adds bearer-token authentication, defaults the bind address to loopback, and hardens the attribute checks.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "10.0",
  "pubDate": "2026-08-27T17:20:51.950Z",
  "pubdate": "2026-08-27T17:20:51.950Z",
  "executiveSummary": "ToolUniverse versions prior to 1.3.0 are subject to a critical remote code execution vulnerability originating from an insecure sandbox implementation and exposed administrative interfaces.\nThe vulnerability stems from a deficient denylist-based security filter in the python_code_executor tool, which fails to prevent advanced attribute-lookup techniques. This allows attackers to bypass restrictions and access sensitive Python internals, including the subprocess module, to achieve arbitrary command execution.\nFurthermore, the http_api_server.py and smcp_server.py components were configured by default to bind to all network interfaces without authentication and with debugging enabled. This creates a critical risk where any network-adjacent actor can gain full control over the host process.\nThe combination of a sandbox escape and an unauthenticated, globally accessible API results in a high-severity risk, enabling remote attackers to achieve full system compromise with the privileges of the server process.\nSuccessful exploitation requires no prior authentication and can be performed by any actor with network visibility to the service ports.",
  "technicalDetails": "The vulnerability is located in the python_code_executor tool, specifically within the implementation of the sandbox environment defined in python_executor_tool.py. The primary root cause is an ineffective security model based on a denylist of forbidden attribute names and function calls.\nThe filter fails to recursively inspect or restrict access to dunder attributes when they are invoked through dynamic string-based lookups or chained attribute access. By leveraging this design flaw, an attacker can traverse the object hierarchy starting from standard literals (e.g., an empty string or integer). By accessing the __class__ attribute, then transitioning to the object base via __base__, and finally using __subclasses__(), an attacker can enumerate loaded classes within the runtime memory space.\nThrough this enumeration, the attacker can recover references to restricted modules such as os and subprocess, effectively circumventing the intended sandbox protections to execute arbitrary system commands.\nAdditionally, the vulnerability is exacerbated by a secondary injection flaw in the python_code_executor tool. A per-call argument allows the caller to modify the import allow-list before the security inspection logic is triggered, granting the attacker control over the sandbox environment's configuration.\nThe network exposure is critical due to the implementation of http_api_server.py and smcp_server.py. These services were configured to bind to all available network interfaces (0.0.0.0) without enforcing authentication, while simultaneously exposing debugging functionality. This configuration allows any remote user capable of establishing a network connection to these services to submit arbitrary payloads.\nThe exploitation flow proceeds as follows: 1) The attacker connects to the exposed HTTP or MCP service without authentication. 2) The attacker submits a crafted payload to the python_code_executor. 3) The attacker modifies the import allow-list via the per-call argument. 4) The attacker utilizes dynamic dunder-attribute lookups to escape the execution sandbox. 5) The attacker invokes subprocess or os modules to execute system-level commands with the privileges of the service user.\nThe impact includes full remote code execution, potential lateral movement within the network, and complete compromise of the underlying host operating system."
}