- RunSybil says a memory flaw in CPython lets a booby-trapped AI model escape its template sandbox and run code on the server that loads it.
- CPython's security team says sandboxing untrusted Python is outside its threat model. RunSybil says it has found no project willing to own a full fix.
- Ask your AI hosting providers how they isolate uploaded models. RunSybil reports DigitalOcean's layered isolation contained the attack.
A sandbox is a promise, and someone has to keep it
A sandbox is a promise that code can run without touching anything important. Promises need an owner. RunSybil, a security research firm, has published findings that show what happens when the owner is unclear.
The firm says it found a zero-day flaw in CPython, the standard Python interpreter. It says the flaw lets an attacker escape a code sandbox and run code hidden inside a specially crafted AI model. The target is the server that hosts the model.
The AI supply chain increasingly assumes a sandbox will contain untrusted model files. RunSybil's advice is to treat its guarantees as best-effort.
What RunSybil says it did
Chat templates are small Jinja files that structure the conversation between a user and a language model. They ship with the model. Many platforms run them inside a Python sandbox because the file comes from outside.
RunSybil built a backdoored version of the Qwen2.5-0.5B-Instruct model with a rigged chat template file. It then loaded the model in an inference serving engine such as vLLM. The researchers report arbitrary code execution in the serving process.
The firm then sent working demonstration exploits to a range of inference providers. These providers let customers upload models built elsewhere. RunSybil says the providers' responses, and their security postures after exploitation, varied widely.
How the escape works
Python lets you write a type such as a dictionary of text keys and whole-number values. Python can also leave blanks in that type to fill in later. To track those blanks, it records them once in a cached list.
The researchers made an object that changes after that list is built. Python then looks for the new blank in the old list and gets an index of minus one. A safety check meant to catch this is switched off in normal release builds. Python reads memory it should not.
That read can hand the template a live Python object the sandbox meant to hide. RunSybil used a chosen number, built through a tuple's cached hash, to point at the object it wanted. From there it recovered the pieces needed to build and run code.
The firm describes one path, which affects CPython 3.14 and later. It says other paths depend on the interpreter build.
No one has taken on a full fix
The sandbox in question is Jinja's, and the Pallets Project maintains Jinja. It is built on CPython behaviour, and the flaw sits in CPython underneath it.
RunSybil says it told CPython, Hugging Face and the Pallets Project about the flaw. It chose them as the groups best placed to deal with the root cause. It says none of them has yet taken on a complete fix for the people at risk.
The Python Security Response Team told CSO, as reported by InfoWorld, that it acknowledges the underlying bug. It added that it does not consider the demonstrated escape a CPython security vulnerability. CPython's security team says guaranteeing a sandbox for untrusted Python is outside its threat model.
RunSybil says the Jinja maintainers gave a response at odds with CPython's guidance. It says Hugging Face did not answer within the 90-day disclosure window. vLLM acknowledged the report but has not decided whether to offer a mitigation.
RunSybil submitted a public patch for the memory bug to CPython. The Python Security Response Team has said it appreciates the contribution to fixing it. But CPython declined RunSybil's request to backport the patch to older supported versions as a security fix.
RunSybil notes that much of the AI ecosystem still runs Python 3.12. It says organic adoption of the fixes might not arrive until late 2028, when that version reaches end of life.
One more detail matters. RunSybil says a human working with GPT-5.6 Sol found the exploit in less than a day. The researchers argue that memory-safety flaws pose a growing risk as models get better at finding them. That is their view, based on this one case.
What worked, and what to ask
The report names two providers. RunSybil says DigitalOcean guarded its bring-your-own-model service with multi-tier isolation and fully contained the attack. It found no way to move sideways in DigitalOcean's infrastructure. It says AWS worked with it quickly to build a mitigation in Bedrock.
The lesson RunSybil draws is to rely on layers rather than the sandbox alone. It advises assuming an attacker can reach code execution through sandboxes, template engines and expression evaluators.
Leaders can put four questions to their teams and vendors:
Do we or our providers load models or templates from outside sources? If so, what isolates the serving process from other customers and from the cloud account? Which Python version runs those workloads, and is it a security-fix-only release? Has the vendor tested what an escaped template could reach?
A sandbox whose underlying flaw is fixed only in newer Python versions is a hope for everyone still on older ones. The safer plan is to build the walls around it yourself.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: RunSybil.
