AI sandbox escape sparks Python dispute

A backdoored model template can break out of its sandbox and run arbitrary code inside AI inference servers, according to security researchers at RunSybil. The claim, published on the firm's blog, describes a CPython memory-safety flaw that the researchers say lets a specially crafted chat template bypass Jinja's protections during model serving. The Python Security Response Team (PSRT) disputes that characterization, telling CSO that the underlying bug is real but the escape itself falls outside CPython's threat model.

Inside the type-handling bug

The technical core of RunSybil's finding is CPython's handling of generic types. In a blog post describing the research, security researcher Darius Houle wrote that the bug "abuses CPython’s handling of generic types to accomplish a breakout." The researchers used objects that sandboxes make available in every template, even empty ones.

According to the write-up, CPython can keep using a cached list of parameters after an object has been modified through a callback. When the interpreter later looks for a newly introduced parameter in the original list, it can receive an invalid index. An assertion that would normally catch that condition is disabled in release builds, so the interpreter can read memory outside the intended bounds.

That out-of-bounds access is what RunSybil turned into an escape. "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. From those recovered references, the researchers said they could reach the Python classes and functions needed to build executable code.

How the malicious template worked

To show the flaw in practice, RunSybil modified the Qwen2.5-0.5B-Instruct model by inserting a backdoored chat_template.jinja file. When the model was loaded and served through an engine such as vLLM, the template allowed arbitrary code execution inside the serving process. The attack did not require the model weights themselves to be malicious; the template file was enough.

That path matters for any AI hosting provider that lets customers upload and run their own models. A single poisoned template in a bring-your-own-model (BYOM) workflow could, per RunSybil, give an attacker a foothold inside infrastructure that processes requests for multiple customers.

"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.

“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.”

— Darius Houle, security researcher at RunSybil

Python team pushes back

CPython's security team does not accept RunSybil's framing. In a statement to CSO, the PSRT acknowledged the bug and credited the researchers for helping fix it, but drew a line at calling the demonstration a CPython vulnerability.

“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.

— Python Security Response Team

The team pointed to CPython's security policy, which states that sandbox escapes should be handled by the maintainers of the sandboxing software involved. "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 said.

The disagreement is not about whether the bug exists, but about who owns the consequence. RunSybil argues the interpreter's behavior creates risk for AI inference infrastructure. The PSRT says running untrusted Python inside a sandbox is not a boundary CPython promises to enforce.

Disclosure friction and a missing backport

RunSybil said it disclosed the issue to CPython, the Pallets Project (which maintains Jinja), and Hugging Face, and encountered conflicting views about which project should fix the underlying problem. The PSRT also disputed the researchers' suggestion that there was no coordinated remediation process, noting that the report arrived by email rather than through CPython's designated private GitHub vulnerability reporting channel.

A patch from RunSybil was merged into CPython's main development branch on Aug. 14. According to the PSRT, the fix was backported to the 3.13, 3.14, and 3.15 branches as a regular bug fix, not as a security fix. That classification is central to RunSybil's remaining concern: the researchers say no backport was made to Python 3.12.

"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 numbers behind the dispute

• A patch was merged into CPython's main branch on Aug. 14.
• The fix was backported to Python 3.13, 3.14, and 3.15.
• No backport was made to Python 3.12, according to RunSybil.
• The researchers warn that organic adoption of the fix may not arrive until late 2028, when Python 3.12 reaches end-of-life.
• The demonstration used the Qwen2.5-0.5B-Instruct model with a backdoored chat_template.jinja file.

Where the sandbox boundary sits

Jinja is a Python-based templating engine used to structure interactions between users and large language models. In an inference server, the chat template decides how a conversation is formatted before it reaches the model. That makes it a piece of code the server executes on behalf of whoever supplies the model — a detail that sits at the heart of the disagreement.

For RunSybil, the escape shows that a template engine can become an entry point into the serving process. For CPython, the interpreter was never meant to be the wall around that process. Both sides agree the bug was real and worth fixing; they split on whether the fix changes the security story.

The researchers said they shared proof-of-concept exploits with multiple inference providers that support bring-your-own-model features. They recommend that AI hosting providers treat sandboxed code, template engines, and expression evaluators as best-effort controls rather than standalone security boundaries.

What it means for AI hosting providers

The practical takeaway for anyone running inference infrastructure is that the layers around a model — templates, expression evaluators, sandboxed code — may not hold up as hard security boundaries. RunSybil's own guidance points in that direction: assume a poisoned template can reach the serving process, and design accordingly.

For providers offering BYOM features, the question is whether customer-supplied templates are treated with the same suspicion as customer-supplied code. The researchers' demonstration suggests a template file alone can be enough to execute code, which puts the review and isolation of those files on the same footing as any other untrusted artifact in the pipeline.

The backport gap adds a second problem. If the fix does not reach Python 3.12, deployments pinned to that branch may remain exposed to the underlying bug even after the patch lands elsewhere. RunSybil's timeline — no organic adoption until late 2028 — is its own estimate, but it describes a familiar pattern in which a fix exists in the development branch while production systems stay on an older release.

None of this resolves the classification fight. CPython's position is that sandbox escapes belong to the sandbox maintainers; RunSybil's is that the interpreter's memory-safety behavior made the escape possible. Until the two sides agree, AI providers may find themselves deciding which interpretation to plan around — and the safer assumption is the one that treats the sandbox as a speed bump rather than a wall.