CVE-2025-62164: 
NixOS vulnerability analysis and mitigation

CVE-2025-62164 is a memory corruption vulnerability in vLLM, an inference and serving engine for large language models, affecting the Completions API endpoint. The flaw allows authenticated attackers to trigger denial-of-service (DoS) and potentially achieve remote code execution (RCE) by supplying maliciously crafted prompt embeddings. It affects vLLM versions 0.10.2 through 0.11.0 (inclusive of release candidates 0.11.1-rc0 and 0.11.1-rc1), and was disclosed on November 20, 2025, by the AXION Security Research Team. The vulnerability carries a CVSS v3.1 base score of 8.8 (High) (Github Advisory, vLLM Advisory).

The root cause is unsafe deserialization of untrusted data (CWE-502) combined with improper input validation (CWE-20), leading to an out-of-bounds write (CWE-787) and a write-what-where condition (CWE-123). The vulnerable code resides in vllm/entrypoints/renderer.py in the _load_and_validate_embed() function, which calls torch.load() with weights_only=True on user-supplied base64-encoded tensors without wrapping the operation in torch.sparse.check_sparse_tensor_invariants. A behavioral change introduced in PyTorch 2.8.0 disabled sparse tensor integrity checks by default, meaning a maliciously crafted sparse tensor can bypass internal bounds checks and trigger an out-of-bounds memory write when to_dense() is subsequently called. An attacker with API access can submit a crafted prompt_embeds payload to the Completions API endpoint to exploit this flaw (vLLM Advisory, Github Advisory).

Successful exploitation can crash the vLLM server process (denial of service) and potentially allow an authenticated attacker to execute arbitrary code on the server hosting vLLM. A full compromise of the vLLM server process could expose confidentiality, integrity, and availability of the hosted LLM infrastructure, including model weights, inference data, and any secrets accessible to the server process. Deployments running vLLM as a public-facing API server or any instance that deserializes untrusted payloads are at highest risk, with potential for lateral movement within the hosting environment if the server process has broad system privileges (vLLM Advisory, Github Advisory).

1. Reconnaissance: Identify vLLM server instances (versions 0.10.2–0.11.0) exposed via the Completions API endpoint, using network scanning or service enumeration tools. Confirm the target is running PyTorch 2.8.0 or later, which disables sparse tensor integrity checks by default.
2. Obtain API credentials: Acquire valid API credentials or tokens with at least low-privilege access to the vLLM Completions API endpoint.
3. Craft malicious sparse tensor: Using PyTorch, construct a malformed sparse tensor with invalid internal metadata (e.g., out-of-bounds indices) that would normally be rejected by sparse tensor integrity checks but passes through torch.load() with weights_only=True under PyTorch 2.8.0+.
4. Serialize and encode payload: Serialize the malicious tensor using torch.save() and encode the resulting bytes as a base64 string.
5. Submit crafted request: Send an HTTP POST request to the vLLM Completions API endpoint with the malicious base64-encoded tensor in the prompt_embeds field of the JSON body.
6. Trigger memory corruption: The server's _load_and_validate_embed() function deserializes the tensor via torch.load() without sparse integrity checks, then calls to_dense(), triggering an out-of-bounds memory write that crashes the server (DoS) or potentially enables code execution (vLLM Advisory, Github Advisory).

• Network: Unusual or repeated HTTP POST requests to the vLLM Completions API endpoint (/v1/completions) containing a prompt_embeds field with large or anomalous base64-encoded payloads; unexpected outbound connections from the vLLM server process following such requests.
• Logs: vLLM server logs showing crashes, segmentation faults, or unhandled exceptions originating from vllm/entrypoints/renderer.py or PyTorch's to_dense() call; repeated 500-series HTTP error responses correlated with prompt_embeds submissions.
• Process: Unexpected child processes spawned by the vLLM Python process (e.g., shells, network utilities); sudden termination and restart of the vLLM server process without administrative action.
• File System: Unexpected new files or scripts written to the vLLM working directory or system temp directories following API requests with prompt_embeds payloads.

The primary remediation is to upgrade vLLM to version 0.11.1 or later, which introduces the --enable-prompt-embeds flag that must be explicitly set to allow loading of user-supplied prompt embeddings — the feature is disabled by default in the patched release (vLLM Advisory, vLLM PR #27204). Red Hat has also issued errata (RHSA-2025:23209, RHSA-2025:23205, RHSA-2025:23449, RHSA-2026:3462) for affected Red Hat AI Infrastructure Service packages (Red Hat CVE). As interim workarounds, operators should restrict API access to trusted users and networks, implement network segmentation to isolate vLLM services, and monitor for anomalous prompt_embeds submissions. If the prompt_embeds feature is not required, ensure it remains disabled (the default in v0.11.1+).

The vulnerability was discovered and responsibly disclosed by the AXION Security Research Team (Omri Fainaro, Bary Levy), with coordinated disclosure through the vLLM project maintainers (vLLM Advisory). Security media outlets including GBHackers, CyberSecurityNews, SecurityOnline, and eSecurity Planet covered the disclosure, highlighting the risk to AI/LLM infrastructure (GBHackers, SecurityOnline). Salt Security published a blog post framing the vulnerability as exposing the "soft underbelly of AI infrastructure," emphasizing the broader risk of unsafe deserialization in LLM serving frameworks (Salt Security). The Hacker News included it in a weekly CVE recap, reflecting broader community awareness (The Hacker News).