CVE-2025-62164: vllm · Improper Input Validation
Affects vllmSource CVE Database V5
Not known to be exploited · CVSS 8.8 High : upgrade to 0.11.1 soon.
Data as of 26 Oct 2026, 06:26 UTC
- EPSS
- 0.9% chance of exploitation in 30 days – higher than 61% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.11.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 21 Nov 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.
What to do
Upgrade vllm-project/vllm to 0.11.1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubvllm-project/vllmpkg:github/vllm-project/vllmOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
To mitigate CVE-2025-62164, organizations should immediately upgrade all vLLM deployments to version 0.11.1 or later, where the vulnerability is patched. Until upgrades are complete, restrict network access to the Completions API endpoint to trusted users and systems only, employing network segmentation and firewall rules. Implement strict input validation and sanitization on all user-supplied tensor data before deserialization, potentially adding custom checks to detect malformed or suspicious tensor structures. Monitor logs and network traffic for anomalous tensor payloads or unusual API usage patterns that could indicate exploitation attempts. Employ runtime protections such as containerization or sandboxing of vLLM processes to limit the impact of potential code execution. Regularly audit and update dependencies, including PyTorch, to ensure security features like sparse tensor integrity checks are enabled. Finally, maintain an incident response plan tailored to AI service compromises, including rapid isolation and forensic analysis capabilities.
Description
vLLM is an inference and serving engine for large language models (LLMs). From versions 0.10.2 to before 0.11.1, a memory corruption vulnerability could lead to a crash (denial-of-service) and potentially remote code execution (RCE), exists in the Completions API endpoint. When processing user-supplied prompt embeddings, the endpoint loads serialized tensors using torch.load() without sufficient validation. Due to a change introduced in PyTorch 2.8.0, sparse tensor integrity checks are disabled by default. As a result, maliciously crafted tensors can bypass internal bounds checks and trigger an out-of-bounds memory write during the call to to_dense(). This memory corruption can crash vLLM and potentially lead to code execution on the server hosting vLLM. This issue has been patched in version 0.11.1.