Three separate vulnerabilities in vLLM, the dominant open-source inference serving framework, allow attackers to crash your entire inference pool with a 100-byte request, execute arbitrary code via shared memory handle forgery, or achieve remote code execution through processor revision handling. The fix is a single version upgrade. All three issues are addressed in v0.32.0.
The three vulnerabilities
DoS via chat template injection
A 100-byte crafted request to the chat completions API can block all tenants sharing an inference pool indefinitely. The vulnerability is in vLLM's chat template processing code, which fails to bound execution time for certain template patterns. A single malicious request causes the template engine to loop, consuming the inference worker thread and preventing legitimate requests from being served.
This requires no authentication if your vLLM endpoint is exposed without an API key. Even with authentication, any authenticated user can trigger a denial of service affecting all other users on the same instance.
RCE via shared memory handle forgery
vLLM uses shared memory for high-performance data transfer between inference workers. An attacker who can submit requests to the API can forge a shared memory handle that causes the receiver to call pickle.loads on attacker-controlled data. Pickle deserialization is a well-established arbitrary code execution primitive in Python. This vulnerability enables a remote attacker to execute arbitrary code with the privileges of the vLLM process, which typically runs with broad system access.
Processor revision RCE
A third code path in vLLM's processor revision handling contains a separate remote code execution vulnerability. Technical details are limited at time of writing. The fix is included in the v0.32.0 release.
Fix and mitigation
Upgrade vLLM to v0.32.0 or later. This is the definitive fix for all three vulnerabilities. If you cannot immediately upgrade, disable the multimodal shared memory cache as a partial mitigation for the shared memory RCE. This does not address the DoS or processor revision RCE.
Who is affected
Any organization running vLLM as an inference server is potentially affected. vLLM is widely deployed in internal AI tooling stacks, customer-facing AI products, research infrastructure running open-weight models, and multi-tenant AI platforms serving multiple teams or customers from a shared instance.
The DoS vulnerability is particularly dangerous for multi-tenant deployments, where a single low-privileged user can affect all other users. The RCE vulnerabilities represent a full system compromise if exploited.
The broader pattern
These three vulnerabilities reflect a pattern in AI inference software: code originally written for research environments, where inputs are trusted, is now deployed in production environments with untrusted inputs. Chat template processing, shared memory IPC, and model processor code were not originally designed to handle adversarial inputs.
As organizations move from cloud AI APIs to self-hosted inference, the security responsibility shifts from the cloud provider to the organization. vLLM is not unique in having vulnerabilities of this type. All AI inference frameworks deserve the same scrutiny as any other network-accessible service.
Source: Adversa AI November 2026 AI security roundup.
Written by Gigia Tsiklauri, Security Architect and AI Security specialist at Infosec.ge.