GHSA-ggpf-24jw-3fcw: vLLM: RCE via malicious model, PyTorch < 2.6 bypass

## Description https://github.com/vllm-project/vllm/security/advisories/GHSA-rh4j-5rhw-hr54 reported a vulnerability where loading a malicious model could result in code execution on the vllm host. The fix applied to specify `weights_only=True` to calls to `torch.load()` did not solve the problem prior to PyTorch 2.6.0. PyTorch has issued a new CVE about this problem: https://github.com/advisories/GHSA-53q9-r3pm-6pq6 This means that versions of vLLM using PyTorch before 2.6.0 are vulnerable to this problem. ## Background Knowledge When users install VLLM according to the official manual  But the version of PyTorch is specified in the requirements. txt file  So by default when the user install VLLM, it will install the PyTorch with version 2.5.1  In CVE-2025-24357, weights_only=True was used for patching, but we know this is not secure. Because we found that using Weights_only=True in pyTorch before 2.5.1 was unsafe Here, we use this interface to prove that it is not safe.  ## Fix update PyTorch version to 2.6.0 ## Credit This vulnerability was found By Ji'an Zhou and Li'shuo Song

An adversary publishes a malicious PyTorch model file (.pt/.pth) to a public registry such as HuggingFace Hub, embedding a Python pickle payload that executes a reverse shell on deserialization. A developer or automated CI/CD pipeline pulls this model and loads it via vLLM running PyTorch 2.5.1 — the default pinned version. Despite `weights_only=True` being set (the CVE-2025-24357 fix), a known gadget chain in PyTorch < 2.6.0 bypasses the restriction. Code executes on the inference host with the privileges of the vLLM process, typically on a GPU server with broad internal network access. The attacker now has a foothold in the ML infrastructure with access to model weights, API keys stored in environment variables, and adjacent cloud services.