IBM mcp-context-forge 的 CVE-2026-53710 漏洞可讓程式碼逃出沙箱

The Sandbox That Was Not One: CVE-2026-53710 in IBM mcp-context-forge

An MCP gateway exists to sit between an AI client and a set of tools, and IBM's mcp-context-forge includes a python_sandbox_server component meant to execute untrusted code safely. A flaw tracked as CVE-2026-53710, published as GHSA-xm98-3vcf-fph7 with a CVSS base score of 10.0, defeats that component entirely. Versions before 1.0.2 are affected.

The escape in one paragraph

The sandbox exposes a dictionary of safe_builtins intended to limit what executed code can reach. That dictionary exposes a raw reference to getattr. With getattr available, a script inside the sandbox can walk the dunder attributes of ordinary Python objects until it reaches a class tree that leads to subprocess.Popen, then start a process outside the sandbox. The execute_code interface that accepts the code is reachable over HTTP and SSE without authentication, so no credential is required to attempt the escape.

Why a builtins allowlist fails here

The design intent of a safe_builtins list is to remove the dangerous primitives and leave the harmless ones. That framing creates a structural problem. Python's object model is connected, and getattr is the function that traverses it. Removing names from a dictionary does not remove the graph, and one traversal primitive that survives the filter can rebuild the rest. Sandbox hardening in Python tends to converge on a different answer: a separate process, a restricted interpreter, or a container with no ambient privileges, instead of a curated list of names inside the same interpreter.
The severity score of 10.0 reflects that the escape is remote, unauthenticated and complete. It does not describe a measured incident, and the advisory claims no exploitation.

What operators should check

Upgrade mcp-context-forge to 1.0.2 or later. Then check exposure. An MCP gateway is often deployed for internal convenience and left reachable on a network segment that is broader than intended, and the execute_code endpoint is the specific surface that matters. Confirm whether the service is reachable from anywhere beyond the hosts that need it, and treat network placement as part of the fix instead of an optional hardening step.
Where the gateway must run, isolate the code execution path at the operating system layer. Run it as a dedicated user with no access to credentials, mount no host directories, and cap memory and CPU. If the integration does not need code execution at all, disabling that tool removes the attack surface instead of mitigating it.
Logging deserves attention too. Because the escape travels through ordinary Python operations rather than a distinctive payload, request-level content inspection is unlikely to distinguish exploitation from normal use. Process creation on the gateway host, especially by the account that runs the sandbox, is the more reliable signal.

References

• GitHub Security Advisory GHSA-xm98-3vcf-fph7 for CVE-2026-53710.
• IBM mcp-context-forge release notes for version 1.0.2.