What happened
ContextForge's Python code-execution sandbox for MCP tool calls can be escaped via runtime-constructed dunder attribute names and an exposed raw getattr builtin, allowing arbitrary code execution rather than the restricted subset the sandbox is meant to enforce.
Why it matters
MCP Context Forge is positioned as a centralized AI gateway/registry/proxy for MCP, A2A, and REST/gRPC APIs; a sandbox escape in its code-execution tool converts what operators believe is a safely restricted 'run some Python' capability for agents into unauthenticated remote code execution on the gateway itself, with a public PoC already available.
Attack vector
The sandbox exposes raw getattr through safe_builtins (bypassing mediated attribute access), and code-validation only checks for literal dangerous dunder strings while allowing them to be constructed at runtime. Combined with the execute_code MCP tool being reachable over unauthenticated HTTP/SSE transport, an attacker can submit Python that dynamically reconstructs blocked names (e.g. to reach subprocess/Popen) and execute arbitrary OS commands with the server process's privileges. A working proof-of-concept has been published.
Affected systems
IBM/mcp-context-forge python_sandbox_server sub-project, prior to 1.0.2/1.0.3
Mitigation
Upgrade mcp-context-forge / python_sandbox_server to the patched release (1.0.2 or later per the referenced fix commit); require authentication on the execute_code MCP tool and restrict network reachability of the sandbox server regardless of patch status.