vLLM versions before 0.31.0 contain two remote denial-of-service bugs in multimodal request handling, published as CVE-2026-114055 (high, CVSS 7.5) and CVE-2026-114050 (moderate, CVSS 6.5). If you serve a vision or video model with vLLM and any client you do not control can reach the API, upgrade to 0.31.0. Neither bug exposes data or runs code, but either can take the whole server down with a small request.
This is a vLLM vulnerability that matters to anyone whose coding agents or internal tools call a self-hosted model. The agent is only as available as the endpoint behind it. The tool's page in the Beam CVE database is vLLM.
Quick answers
| Question | Answer |
|---|---|
| Am I affected? | If you run vLLM below 0.31.0 and serve multimodal models. CVE-2026-114055 covers >= 0.7.3, < 0.31.0. |
| Is there a fix? | Yes: 0.31.0, per both advisories. |
| How bad is it? | Availability only. A request can crash the API server, a worker or the whole engine. |
| Does it need credentials? | CVE-2026-114055 needs none per its CVSS vector. CVE-2026-114050 is described as unauthenticated, though its vector lists low privileges; see below. |
| Does data leave my machine? | Not through these bugs. They cause crashes, not disclosure. |
| Is there a workaround? | None is listed. Restrict who can reach the endpoint. |
CVE-2026-114055: client-controlled processor arguments
vLLM lets an API client send mm_processor_kwargs with each request. These are keyword arguments passed to the multimodal processor that prepares images and video for the model. According to the advisory, vLLM forwards them into Hugging Face and custom processor constructors without validating them. That means a remote client can influence values such as image size, patch count, crop count or frame count.
For processors that upscale or tile their input, those values multiply memory use. One request with a large setting can push the process out of memory, which terminates the API server or the worker. The advisory points to the Isaac processor as a high-amplification path and says InternVL-derived processors, H2OVL, Step3VL and NemotronVL forward the arguments in a similar way. The per-request field was introduced in commit 041e294, which is why the affected range starts at 0.7.3.
The weakness is classified as CWE-400 (uncontrolled resource consumption). The vector is network-reachable, low complexity, no privileges, no user interaction, with high availability impact. Credit goes to the reporter Chedrian07, with jperezdealgaba coordinating and DarkLight1337 reviewing the fix.
What the fix changes
The remediation described in the advisory is to reject non-empty per-request mm_processor_kwargs by default. Operators who serve only trusted clients can opt in to the old behaviour. The server-level --mm-processor-kwargs option and offline LLM overrides remain available, so you can still tune processors yourself, you just cannot let an arbitrary caller do it. The change is merged in vLLM pull request 58830.
The practical consequence: if you have a client that deliberately sends per-request kwargs, it will start to fail after the upgrade unless you opt in. Check for that before rolling out.
CVE-2026-114050: a forged UUID and two caches that drift apart
The second advisory is subtler. Multimodal content parts accept a client-supplied uuid, which vLLM uses as the identity of that image or video in its processor cache. The advisory explains that there are two independent caches, one in the API process and one in the EngineCore process, and that they evict entries without coordinating.
The attack chain, in order:
- The attacker sends a request that places an item in the cache under an identifier of their choosing.
- Evictions in the two caches drift apart, so one side holds a stale entry for that identifier while the other does not.
- The attacker sends a request that reuses the identifier for different content. The EngineCore cache hit path does not check that the cached item matches the current request.
- The token counts no longer agree. vLLM raises an exception that nothing catches, and the engine process dies.
The advisory says the whole serving instance goes down and has to be restarted. Because one forged identifier is enough, a repeat sender can keep it down. The weakness is CWE-345 (insufficient verification of data authenticity), reported by C1ves and JSGforever.
One inconsistency to be aware of: the advisory text describes the attack as unauthenticated, but its CVSS vector lists privileges required as low. If you are scoring this for your own risk register, check the NVD entry. If your API sits behind a key, assume that anyone holding a key can trigger it.
The suggested maintainer-side fixes are to validate cache hits against the request, to turn a token-count mismatch into a per-request error, to bind cache identity to content, and to synchronise evictions. All of this ships in 0.31.0.
Who is affected
You are in scope if you run the vllm pip package (or a container built from it) below 0.31.0 and serve a multimodal model. Text-only deployments do not use the multimodal processors, although upgrading is still sensible.
Exposure depends on who can send requests. A vLLM server bound to localhost for one developer is a low risk. A shared inference endpoint that internal agents, CI jobs or a public demo can call is the case to prioritise. Our earlier coverage of exposed AI endpoints being abused shows how quickly attackers find open model servers, and an open vLLM port is an attractive target even when the only gain is disruption.
The advisories were published on October 6, 2026 and updated on October 23. We found no report of exploitation in the wild in either advisory.
What this means if you run AI coding agents
If your agents call a self-hosted vLLM endpoint, work through this list.
- Check the version. On the serving host, run
pip show vllmand read theVersionline. For containers, check the image tag and its digest, not just the tag name. - Upgrade to 0.31.0. Pin it explicitly, for example
pip install "vllm==0.31.0", and rebuild images instead of patching in place. Follow vLLM's own release notes for any other breaking changes in your jump. - Audit callers that send
mm_processor_kwargs. After the upgrade, per-request kwargs are rejected by default. Move legitimate settings to the server-level--mm-processor-kwargsoption rather than enabling the override for everyone. - Put authentication in front of the endpoint. vLLM supports an API key, and a reverse proxy can add per-client rate limits and request size caps. This is general hardening, not text from the advisory, but it limits who can send a crafted request.
- Look for the symptoms. Repeated out-of-memory kills, an engine process that exits and is restarted by your supervisor, or an uncaught token-count mismatch exception in the logs are what these bugs leave behind. Correlate them with the client addresses in your access logs.
- Make the agent side tolerant. Agents that retry a dead endpoint in a tight loop make recovery harder. Use backoff and fail over to a hosted model where policy allows.
The broader lesson is the one in our guide to AI agent application and supply-chain security: the inference server is part of the agent's trust boundary, and request fields that look like tuning knobs are attack surface. See also MCP security in practice for the tool side, and the October 2026 supply chain incidents tracker for what else has been hitting AI infrastructure this month.
How this compares with other serving bugs
Denial of service in model servers is rarely dramatic, but it is a recurring pattern: a field the API accepts for flexibility becomes a lever on memory or compute. Here the lever is a processor argument in one case and a cache key in the other. In both, the server trusted a value that came from the caller. The same shape appears in prompt-injection and tool-call bugs, where a model or agent trusts text that came from outside. If you maintain your own gateway, the lesson is to validate or ignore per-request settings that change resource use, and never let a client-chosen identifier decide cache identity.
What Beam can and cannot do here
Beam does not apply to this bug. It runs on a developer machine, watching what Claude Code, Codex and similar agents do, flagging risky actions such as credential exposure and destructive commands, and scanning skill and MCP configurations with a set of heuristics and a version-pin check. It does not inspect model-serving software, network requests to a vLLM server, or Python packages on a remote host. For this advisory your controls are the version upgrade, authentication and network limits. If an agent's session logs show repeated failures against your inference endpoint, Beam's local, on-device history can help you see which sessions were calling it, but it will not stop a crash on the server.
If you want to monitor a self-hosted service for risky log content, monitoring a running app with beam monitor covers a watch-only mode that flags credentials written to logs. It is heuristic and does not detect resource-exhaustion attacks.
Related context
OpenAI's disclosure thinking is relevant when bugs like these are found by AI tools at scale; see OpenAI's Patch the Planet framework. Both advisories here were coordinated and published on October 6, with fixes in the same release, which is the orderly pattern that framework describes.
Frequently asked questions
Which vLLM versions are affected by CVE-2026-114055 and CVE-2026-114050?
CVE-2026-114055 affects vLLM from 0.7.3 up to, but not including, 0.31.0. CVE-2026-114050 is listed as affecting versions before 0.31.0. Both advisories name 0.31.0 as the patched release.
How severe are these vulnerabilities?
CVE-2026-114055 is rated high with a CVSS 3.1 score of 7.5. CVE-2026-114050 is rated moderate at 6.5. Both affect availability only; the advisories list no confidentiality or integrity impact.
Is there a workaround if I cannot upgrade yet?
Neither advisory lists a user-side workaround. The practical stopgap is to stop untrusted clients from reaching the multimodal endpoint, for example by putting authentication or an allowlist in front of it. That is our suggestion, not the advisory text.
Do these bugs expose data or let an attacker run code?
No. Both are denial-of-service bugs: one exhausts memory in the API server or worker, the other crashes the engine process. The advisories report no data exposure or code execution.
Why does this matter for people running coding agents?
Teams often point coding tools or custom agents at a self-hosted vLLM endpoint. If that endpoint crashes, every agent depending on it stops, and a restart loop can hide the cause. Treating the server as a service that untrusted callers must not reach is the fix.
Can Beam detect or block this?
No. Beam watches coding-agent actions and scans skill and MCP configurations on your machine; it does not inspect inference servers or their requests. Use version pinning, authentication and network controls for vLLM.
Related reading
- Symantec: agents abusing exposed AI endpoints
- AI agent application and supply-chain security
- MCP security in practice
- How Beam keeps data local
Versions and advisory details are accurate as of October 23, 2026. Check the linked GitHub advisories and vLLM's release notes for changes.