CPython flaw exposes AI inference servers to sandbox escape attacks
CSO Online ·
A memory-safety flaw in CPython can allow malicious AI model templates to escape code sandboxes and execute arbitrary code inside inference servers, according to security researchers at RunSybil. “By exploiting this vulnerability, attackers could gain a foothold inside servers responsible for processing millions of user requests,” Darius Houle, a security researcher at RunSybil, wrote in a blog post. “They also could strike directly at the underlying cloud infrastructure hosting those workloads.” The researchers demonstrated how a specially crafted model could exploit the flaw to bypass Jinja, a Python-based templating engine used to structure interactions between users and LLMs, sandbox protections, and execute code in the process of serving the model. The attack could expose AI hosting providers that allow customers to upload and run their own models, potentially giving attackers a foothold inside infrastructure processing requests for multiple customers, the post added. However, the Python Security Response Team (PSRT), which handles security reports involving CPython, disputed the security implications of the demonstration in a response to CSO. “We acknowledge the underlying CPython bug reported by RunSybil and appreciate their contribution to fixing it. However, we do not consider the demonstrated sandbox escape to be a CPython security vulnerability,” the team said. The disagreement centres on whether the interpreter should be responsible for preventing sandbox escapes. While RunSybil argues that the flaw creates risks for AI inference infrastructure, PSRT says executing untrusted Python code within a sandbox is outside CPython’s security threat model. Exploiting Python’s type-handling mechanism “The bug we discovered abuses CPython’s handling of generic types to accomplish a breakout,” Houle wrote. “We exploited it using objects that sandboxes make available in every template, even in empty sandbox contexts.” The researchers found that CPython can use a cached list of parameters even after an object has been modified through a callback. When the interpreter subsequently looks for a newly introduced parameter in the original list, it can receive an invalid index. An assertion designed to catch the condition is disabled in normal release builds, allowing the interpreter to access memory outside the expected bounds. RunSybil used this behavior to retrieve references to Python objects that the sandbox was supposed to keep inaccessible. “While an invalid address will generally crash the interpreter, an address pointing to a useful live Python object gives our callback a reference to that object (even when the sandbox never intends to expose it),” Houle wrote. The researchers then used the recovered object references to access Python classes and functions needed to construct executable code. Malicious model templates enable code execution To demonstrate the attack, RunSybil modified the Qwen2.5-0.5B-Instruct model by inserting a backdoored chat_template.jinja file. When the model was loaded and used through an inference-serving engine such as vLLM, the template enabled arbitrary code execution in the serving process. “Breaking out of the chat template sandbox and executing code represents a supply chain risk that endangers inference providers, library developers, and model users,” Houle wrote. The researchers said they shared proof-of-concept exploits with multiple inference providers supporting bring-your-own-model (BYOM) features, which allow customers to upload models from external sources. Python disputes vulnerability classification RunSybil disclosed the issue to CPython, the Pallets Project, which maintains Jinja, and Hugging Face. The researchers said they encountered conflicting views about which project should address the underlying problem. CPython maintains that the interpreter does not support sandboxing untrusted Python code as a security boundary. In its response to CSO, the PSRT referred to the project’s security policy, which states that sandbox escapes should be addressed by the maintainers of the affected sandboxing software. “Escapes from such sandboxes are therefore outside our security threat model and should be addressed by the maintainers of the affected sandboxing software,” the team said. The team also disputed RunSybil’s suggestion that there was no coordinated remediation process. It said the researchers had submitted the report by email rather than through CPython’s designated private GitHub vulnerability reporting channel. Fix backported to three Python branches RunSybil submitted a patch to CPython, which was merged into the main development branch on Aug. 14. According to the PSRT, the fix was also backported to the 3.13, 3.14, and 3.15 branches as a regular bug fix rather than a security fix. The distinction matters because RunSybil had raised concerns that the fix would not reach all supported Python versions. The researchers said the absence of a backport to Python 3.12 could delay adoption of the fix across AI infrastructure deployments. “With major portions of the AI ecosystem still solidly aligned on Python 3.12, we might not see organic adoption of our memory-safety fixes until late 2028, when it reaches its end-of-life date,” Houle wrote. The researchers recommend that AI hosting providers treat sandboxed code, template engines and expression evaluators as best-effort security controls rather than relying on them as standalone security boundaries.