CVE-2025-62164 – vLLM Prompt Embedding Bug Enables AI RCE Risk

CVE-2025-62164 is a memory corruption vulnerability in vLLM versions 0.10.2 and later that exposes AI inference servers to denial-of-service and potential remote code execution via malicious prompt embeddings. The flaw arises in the Completions API path where Base64-encoded embeddings are deserialized using PyTorch’s torch.load() and then converted to dense tensors without integrity checks, mapping to MITRE ATT&CK T1190 (Exploit Public-Facing Application) and T1203 (Exploitation for Client Execution). Any user with access to the public-facing API can send crafted payloads that trigger out-of-bounds writes in memory. The risk is amplified by a PyTorch 2.8.0 change that disabled sparse tensor invariant checks by default, leaving vLLM to assume tensors are valid before calling to_dense(). An attacker can craft malformed sparse tensors whose indices point to invalid memory regions, allowing corruption during densification. Because the vulnerable path is directly exposed through vLLM’s Completions API and often sits behind API gateways or chat front-ends, exploitation requires no prior credentials beyond standard API access. In multi-tenant AI environments, compromise of the vLLM process can expose model weights, in-memory prompts, logs, and adjacent infrastructure. For businesses, the consequences include outage of production LLM services, theft of proprietary model artifacts, or code execution in sensitive AI-serving clusters that often host regulated data and intellectual property. This directly impacts AI-powered customer support, copilots, and internal knowledge tools that drive digital transformation efforts. If exploited, such a flaw could undermine privacy promises, breach contractual SLAs, and violate compliance baselines in frameworks like SOC 2 and ISO 27001 where AI services are in scope. Mitigation requires upgrading to a patched vLLM release and explicitly enabling PyTorch’s sparse tensor integrity checks to restore invariants before densification. Operators should immediately restrict public access to embedding-capable Completions APIs, enforce strong authentication and rate limiting, and validate embedding payloads at API gateways or WAFs. Longer term, security teams should isolate vLLM instances in hardened containers or VMs with least privilege, monitor for crashes and deserialization anomalies, and fold AI-serving components into routine dependency audits, fuzzing campaigns, and secure-by-design reviews.