A memory-safety flaw in CPython can let a malicious AI model template escape its sandbox and run code inside the servers that host large language models, security researchers at RunSybil have shown. The finding turns an ordinary model file into a potential route into AI infrastructure, and it has exposed a sharp disagreement over who should fix it.

The researchers demonstrated the attack by modifying a small open model, Qwen2.5-0.5B-Instruct, and inserting a backdoored chat template file, known as chat_template.jinja. When an inference engine such as vLLM loaded and served the doctored model, the template broke out of the Jinja sandbox and executed arbitrary code in the serving process. Jinja is the templating engine widely used to structure conversations between users and language models.

RunSybil security researcher Darius Houle said attackers exploiting the flaw could gain a foothold inside servers that process millions of user requests. The bug itself abuses CPython's handling of generic types, according to the researchers, who said they found the exploit path in less than a day with human effort paired with an AI coding model.

Python disputes that it is a vulnerability

The Python Security Response Team, which handles security reports for CPython, accepted the underlying bug report and credited RunSybil's contribution to the fix, but rejected the researchers' classification of the sandbox escape as a CPython security vulnerability. In a response to CSO, the team said it did not consider the demonstrated escape to be a CPython security vulnerability.

The disagreement centres on whether the interpreter should be responsible for preventing sandbox escapes. CPython maintains that it does not support sandboxing untrusted Python code as a security boundary, so escapes from such sandboxes fall outside its security threat model and should be addressed by the maintainers of the sandboxing software.

RunSybil disclosed the issue to CPython, the Pallets Project, which maintains Jinja, and Hugging Face, and shared proof-of-concept exploits with inference providers. The researchers submitted a patch that entered CPython's main development branch on 14 August.

Fix reaches newer versions, but not Python 3.12

The patch was backported to Python 3.13, 3.14 and 3.15 as a regular bug fix rather than a security fix, according to the Python Security Response Team. Python 3.12 did not receive a backport, a gap the researchers said could slow uptake among AI infrastructure teams still using that version.

Houle warned that with major portions of the AI ecosystem still aligned on Python 3.12, organic adoption of the memory-safety fix might not arrive until that release reaches the end of its life in late 2028. That leaves a long window in which inference providers running older Python could be exposed if they load model files they have not vetted.

There is no CVE identifier or severity score for the flaw, and no exploitation in the wild has been reported. The practical lesson the researchers draw is blunt: for anyone running bring-your-own-model hosting, a model file is code. Templates should be treated as untrusted, and inference should run in isolation that could withstand attacker-controlled input.

The case adds to a growing cluster of AI supply-chain findings in which the danger sits not in the model weights themselves but in the surrounding files and tooling that servers trust by default. Providers that let customers upload their own models now have one more reason to inspect every file in the package, not just the weights.