Sandboxes only hold if the runtime underneath them does. RunSybil's researchers found a memory-safety bug in CPython that lets a malicious model template break out of its Jinja sandbox and run arbitrary code inside the process serving the model. For anyone running bring-your-own-model inference, that puts the risk on shared infrastructure.
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 the same access "could strike directly at the underlying cloud infrastructure hosting those workloads."
Where the bug lives
Jinja is the Python templating engine that structures conversations between users and LLMs. The researchers showed that a specially crafted model could use it to get past sandbox protections and execute code while the model was being served. The exposure is worst for hosting providers that let customers upload and run their own models, since one malicious upload can reach infrastructure serving multiple tenants.
The mechanism is narrow. CPython can keep using a cached list of parameters after an object has been changed through a callback. When the interpreter looks up a newly added parameter in that stale list, it can get an invalid index. An assertion meant to catch this is disabled in normal release builds, so the interpreter reads memory beyond the expected bounds.
RunSybil used that out-of-bounds access to pull references to live Python objects the sandbox was supposed to hide. As Houle put it, "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)." From there, the team reached the classes and functions needed to construct executable code. Houle noted the exploit relied on objects that sandboxes expose in every template, even empty ones.
A poisoned template in practice
To prove the point, RunSybil modified Qwen2.5-0.5B-Instruct and swapped in a backdoored chat_template.jinja file. When the model loaded through an inference engine such as vLLM, the template ran 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 researchers said they 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 that maintains Jinja, and Hugging Face. The disclosure didn't settle who should act. The Python Security Response Team's position is that CPython doesn't treat itself as a security boundary for untrusted code. Its policy places sandbox escapes with the maintainers of the 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 PSRT also disputed RunSybil's suggestion that no coordinated process existed, noting the report came by email rather than through CPython's private GitHub vulnerability reporting channel. Still, the team acknowledged the underlying bug and thanked the researchers for it. The split is clear: the team accepts the bug, but not the sandbox escape as a CPython vulnerability.
Patch timing and the Python 3.12 gap
RunSybil's patch merged into CPython's main development branch on Aug. 14. 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. Python 3.12 wasn't on that list, and that's where the researchers see the real adoption problem. Houle wrote 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."
The researchers recommend that AI hosting providers treat sandboxed code, template engines and expression evaluators as best-effort security controls, not standalone security boundaries. That's the lesson I'd take from this. If you host uploaded models, don't let a template sandbox be the only wall. Isolate the serving process itself, and check which Python branch your stack actually runs.
