VLLM · GHSA-mwgq-9582-w2vf · AI agents & MCP
FIX → 0.30.0
The OpenAI-compatible API server in vLLM echoed full offending input into every validation error in HTTP 400 responses. A single malformed request producing many errors makes the server spend extra CPU and memory formatting a very large response.
first public Nov 7, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams running the vLLM OpenAI-compatible API server at versions from 0.3.0 up to but not including 0.30.0 are exposed, especially if clients outside their control can send requests to it. Deployments that only serve trusted internal callers are lower risk, and the fix is only in the shared validation error handler, so other endpoints are not described as affected by this text.
Not affected if no-public-api-access, version-0.30.0-or-later
Who cares llm-serving, python, self-hosted, vllm
pip show vllm and compare it to the affected range (>= 0.3.0, < 0.30.0)vllm serve) exposed to clients you do not fully trustversion field of the server's responses or the process's package versionUpgrade to 0.30.0
This was reported as a normal pull request by @hclsys.
The OpenAI-compatible API server's shared RequestValidationError handler rendered all validation errors in its HTTP 400 response. Pydantic errors can include the full offending input, so a single malformed request that generates many errors can cause the same input to be serialized repeatedly.
An API client can trigger a disproportionately large error response. Formatting and sanitizing it consumes CPU and memory on the server, and buffering it can disrupt downstream clients and proxies. @rmonsurate originally reported the behavior on POST /v1/responses in issue #49239.
The shared handler now limits the number of rendered errors and summarizes oversized input values before formatting. It still reports the total error count and how many entries were omitted. The fix bounds error-response rendering. Initial request validation and collection of validation errors still occur.
A fix for this was introduced in https://github.com/vllm-project/vllm/pull/54684.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
vllm 0.30.0 (fixed version per the product data; the fix limits rendered errors and summarizes oversized input values)