A memory-safety bug in CPython can let a poisoned AI model template break out of its sandbox and run arbitrary code inside the process serving the model. The researchers who found it, at RunSybil, say the exposure falls hardest on inference providers that let customers upload their own models. CPython's maintainers see the problem differently.
Darius Houle, a security researcher at RunSybil, laid out the stakes in a blog post: "By exploiting this vulnerability, attackers could gain a foothold inside servers responsible for processing millions of user requests." He added that attackers "also could strike directly at the underlying cloud infrastructure hosting those workloads."
The demonstration targeted Jinja, the Python templating engine that structures exchanges between users and LLMs. A crafted model could slip past Jinja's sandbox protections and execute code while being served. For a hosting provider running customer-supplied models, that means one tenant's model could reach infrastructure serving many others.
How the breakout works
Houle's account centres on how CPython handles generic types. The interpreter can keep using a cached list of parameters even after an object has been modified through a callback. When it then looks up a newly introduced parameter in that stale list, it can receive an invalid index. An assertion meant to catch this is disabled in normal release builds, so the interpreter reads memory outside its expected bounds.
RunSybil used that out-of-bounds read to pull references to Python objects the sandbox was supposed to keep hidden. "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 recovered references gave the researchers access to the classes and functions needed to build executable code.
A backdoored model, end to end
To show the attack working in practice, RunSybil modified the Qwen2.5-0.5B-Instruct model by inserting a backdoored chat_template.jinja file. Loaded and run through an inference engine such as vLLM, the template executed arbitrary code in the serving process. Houle framed it as a supply chain problem: "Breaking out of the chat template sandbox and executing code represents a supply chain risk that endangers inference providers, library developers, and model users." The team shared proof-of-concept exploits with several inference providers that support bring-your-own-model features.
Who owns the fix
RunSybil reported the issue to CPython, the Pallets Project (which maintains Jinja), and Hugging Face, and ran into conflicting views on who should act. CPython's position is that the interpreter doesn't support sandboxing untrusted Python code as a security boundary. Its Python Security Response Team pointed to project policy placing sandbox escapes with 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 PSRT also disputed the suggestion that no coordinated remediation process existed. It noted that the researchers submitted their report by email rather than through CPython's designated private GitHub vulnerability reporting channel. Still, the bug got fixed. RunSybil's patch merged into the main development branch on Aug. 14, and according to the PSRT, it was backported to the 3.13, 3.14, and 3.15 branches as a regular bug fix, not a security fix.
The Python 3.12 gap
That classification matters for deployment. My read is that a fix labelled as an ordinary bug gets slower uptake than a security patch would, and the fact that 3.12 was left out of the backport makes it worse. Houle warned that "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."
RunSybil's advice for hosting providers is to treat sandboxed code, template engines and expression evaluators as best-effort security controls, not standalone security boundaries. If you run a platform that accepts customer models, isolating inference workers at the process or container level looks like a safer bet than trusting any in-process sandbox, whatever version of CPython you're on.
