CVE-2026-81096: ToolUniverse through 1.2.6 Unauthenticated Remote Code Execution via python_code_executor Sandbox Escape
ToolUniverse ran caller-supplied Python inside a sandbox that could be escaped, on a server that required no authentication. The executor behind the pythoncodeexecutor tool, in pythonexecutortool.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 httpapiserver.py and smcpserver.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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ToolUniverseto a version that resolves this vulnerability.Fixed in 1.3.0 - Configuration
Update ToolUniverse to v1.3.0 so the HTTP server binds to the loopback address by default instead of every interface.
ToolUniverse HTTP server (http_api_server.py) bind address = loopback only - Configuration
Update ToolUniverse to v1.3.0 so the MCP server binds to the loopback address by default instead of every interface.
ToolUniverse MCP server (smcp_server.py) bind address = loopback only - Configuration
Update ToolUniverse to v1.3.0 to add bearer-token authentication for requests to prevent unauthenticated remote access.
ToolUniverse HTTP and MCP servers (http_api_server.py, smcp_server.py) authentication = bearer-token enabled
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated exploitation?
ToolUniverse deployments through 1.2.6 are exposed when their HTTP or MCP server port is reachable by an attacker. Those servers bound to every interface, enabled debugging, and required no authentication, so any reachable caller could execute code as the server process.
Does exploitation require credentials, user interaction, or a special server configuration?
No. The affected servers required no authentication, and the vulnerability has no stated user-interaction or privilege requirement. The default network binding exposed the services on every interface with debugging enabled.
What changes in version 1.3.0 reduce the risk?
Version 1.3.0 adds bearer-token authentication, changes the default bind address to loopback, and hardens the sandbox attribute checks. Upgrading addresses both the unauthenticated network exposure and the Python sandbox escape paths described.
What can be done if an immediate upgrade is not possible?
Restrict access to the HTTP and MCP server ports so untrusted callers cannot reach them, preferably limiting exposure to localhost or trusted network paths. Do not allow untrusted users to submit Python to python_code_executor.