Skip to main content
CVE-2025-62164VulnerabilityPublished Updated

CVE-2025-62164: vllm · Improper Input Validation

Affects vllmSource CVE Database V5

0

Not known to be exploited · CVSS 8.8 High : upgrade to 0.11.1 soon.

Data as of 26 Oct 2026, 06:26 UTC

CVSS 3.1 base score
8.8High
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 21 Nov 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
GitHubvllm-project/vllmpkg:github/vllm-project/vllmOther threatsAffected
  • <0.11.1 >=0.10.2
Fixed in
  • 0.11.1

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.

References

Community reviews

Loading reviews…