One Chain to Own Them All - Breaking AI Infrastructures

The talk starts with the growing use of AI tooling and the infrastructure behind it: vector stores, model inference servers and GPU container runtimes. The presenters explain why these components became targets, pointing to recent competitions that featured Ollama, Triton and vLLM. Their search focused on vLLM's completions endpoint, which accepts prompt embeddings, decodes them and passes them to torch.load. They had earlier found a bypass of PyTorch's weights_only mode, and they asked whether the same class of bug could return after the fix.

The middle of the talk walks through a new heap out-of-bounds flaw in the unpickler's tensor rebuild path, which lets a crafted model file declare more elements than its storage holds. The team turned the over-read into an information leak using an error-based technique, then used an out-of-bounds write to overwrite a tensor destructor pointer. On some default Python builds without position-independent executables, the address of the system function was predictable, which removed the need for a separate leak. The same pattern appeared in other products, including ComfyUI, SGLang, NVIDIA Dynamo and OpenLM, where model loading, LoRA or image-embedding inputs reach torch.load.

The main takeaway is that any API that loads models or tensors from user-supplied input is a deserialization surface, even when the model is described as remote rather than local. Teams should not treat weights_only as a complete safety boundary, should audit where torch.load is reachable, and should keep inference servers on patched versions and off unnecessary optional features.