Hosting providers that let customers upload their own model code should read this as an infrastructure bug, not a Python bug.
RunSybil found a route for a malicious model template to break out of a code sandbox and run arbitrary code inside an inference server, and it passes through Jinja, the templating engine that structures user-to-model interaction, on the way to a memory-safety defect in CPython’s type handling.
How the breakout works
The defect involves cached type parameters. An object gets modified through a callback, yet the interpreter keeps consulting the stale list. Ask it for a parameter that was only just introduced and the index it computes can be invalid – a bad read inside structure the interpreter should never expose. Release builds compile out the assertion that would have halted there.
What follows depends entirely on what lands at that address. Usually the interpreter dies. Occasionally the pointer resolves to a live Python object, and the attacking callback now holds a reference the sandbox never meant to hand over. RunSybil mined those references for the classes and functions it needed to assemble working executable code, drawing on objects present in every sandbox, even an empty context.
Whose bug is it
The Python Security Response Team confirmed the underlying defect, shipped a fix, and rejected the security framing. Untrusted Python inside a sandbox falls outside CPython’s threat model, the team told CSO, so an escape is not a CPython vulnerability. RunSybil answers that a multi-tenant interpreter should not be the weakest layer in the stack.
What to change
Treat a sandbox as a bug-reduction measure, never as a trust boundary. Run customer model code in microVMs with a private kernel, and cut the network and filesystem reach the sandbox inherits by default. Then test what it actually blocks.
