CPython bug enables Jinja sandbox escape in AI inference servers, RunSybil says

What happened

Security researchers at RunSybil report a memory-safety flaw in CPython that, they say, lets a malicious AI model template escape the Jinja sandbox and execute arbitrary code inside inference servers. The report comes from CSO Online. RunSybil researcher Darius Houle described the work in a blog post. The Python Security Response Team (PSRT) acknowledges the underlying CPython bug. However, PSRT told CSO that it does not consider the demonstrated sandbox escape to be a CPython security vulnerability.

According to RunSybil, as reported by CSO Online:

• The bug abuses CPython’s handling of generic types. CPython can use a cached list of parameters even after an object has been modified through a callback. This can produce an invalid index.
• An assertion meant to catch this condition is disabled in normal release builds. As a result, the interpreter can read memory outside the expected bounds.
• RunSybil used this behaviour to obtain references to Python objects the sandbox was meant to keep inaccessible. The researchers say they did this with objects that sandboxes make available in every template, even in empty sandbox contexts.
• To demonstrate the attack, RunSybil inserted a backdoored chat_template.jinja file into the Qwen2.5-0.5B-Instruct model. When the model was served through an engine such as vLLM, the template enabled arbitrary code execution in the serving process.
• RunSybil says hosting providers that let customers upload and run their own models (BYOM) could be exposed. The researchers say they shared proof-of-concept exploits with multiple such providers.

RunSybil disclosed the issue to CPython, to the Pallets Project (which maintains Jinja) and to Hugging Face. The researchers say they encountered conflicting views about which project should fix the problem. PSRT says that sandboxing untrusted Python code is outside CPython’s security threat model, and that such escapes should be addressed by the maintainers of the sandboxing software. PSRT also says the report arrived by email rather than through CPython’s private GitHub vulnerability reporting channel (CSO Online).

Several details are not confirmed:

• A CVE identifier.
• The specific Python release versions that contain the fix.
• Any response from the Pallets Project or Hugging Face.
• Any exploitation outside RunSybil’s demonstration.

Am I affected?

Based on the CSO Online report, the scenario described applies if you:

• Serve LLMs with a Python-based engine (vLLM is the example given) that renders model-supplied Jinja chat templates.
• Load models from sources you do not control, especially if you offer bring-your-own-model uploads.
• Run a Python version without the fix. PSRT says the fix was backported to the 3.13, 3.14 and 3.15 branches. RunSybil says there is no backport to 3.12. Houle said much of the AI ecosystem is still on 3.12, and that organic adoption of the fix might not happen until late 2028, when 3.12 reaches end of life.

Which exact patch releases include the fix is not confirmed.

What to do now

1. Inventory which inference services load third-party or customer-uploaded models, and record which Python version each one runs.
2. Where possible, move those services to a 3.13, 3.14 or 3.15 release that includes the fix. PSRT describes the backport as a regular bug fix, so check the release notes for your version (CSO Online).
3. Treat sandboxed code, template engines and expression evaluators as best-effort controls, not standalone security boundaries. This is RunSybil’s recommendation to AI hosting providers (CSO Online).
4. Review chat_template.jinja files in models you did not build before serving them.
5. Watch for updates from CPython, the Pallets Project and Hugging Face. As of this report, a CVE and specific fixed versions are not confirmed.

Sources

• CSO Online: CPython flaw exposes AI inference servers to sandbox escape attacks