Skip to content
feed: live
0dayNews
ai tools
Analysis

vLLM Patches Unauth Memory DoS in 0.25.0

CVE-2026-116177 lets unauthenticated attackers exhaust vLLM inference server memory via Nemotron-VL. Affects 0.10.2 through 0.24.x; patch to 0.25.0.

vLLM Patches Unauth Memory DoS in 0.25.0
Photo: geralt / Pixabay · Pixabay License
kilobaudDave "Kilobaud" Ferris·Published ·2 min read

vLLM, the open-source inference engine behind a large share of production LLM deployments, patched CVE-2026-116177 this week. CVSS 7.5 (high), every release from 0.10.2 through 0.24.x, no authentication required.

The flaw

The vulnerability is in the Nemotron-VL multimodal processor, which globally sets Image.MAX_IMAGE_PIXELS on initialization. That global assignment means any request routed through that code path can trigger memory allocation without bound. An unauthenticated caller can exhaust server RAM through crafted multimodal input, bringing the inference service down without ever establishing credentials.

Why 7.5 understates the operational risk

The score is accurate for what the vulnerability technically is: a denial-of-service with no user interaction and no privilege escalation. The more interesting variable is where vLLM tends to live.

vLLM typically runs on high-memory GPU hosts, where an OOM kill and service restart is more disruptive than taking down a web server. GPU servers are expensive to provision, expensive to restart, and often run inference jobs that can’t be queued and resumed cleanly. In a lot of production setups, the vLLM API sits on an internal port under a “trust the LAN” assumption, with application-layer authentication sitting above it. That’s a reasonable architecture right up until the network perimeter isn’t the boundary it used to be.

A pattern across the AI inference stack

This is the third unauthenticated resource attack against a major AI inference framework covered here in two months. LMCache had an unauthenticated RCE in October. LightLLM carried an unauthenticated RCE via pickle deserialization in September. The pattern is consistent: frameworks designed primarily for research and internal experimentation, pressed into production use faster than the threat model evolved to account for external callers.

vLLM isn’t poorly built. The security gap isn’t code quality; it’s the assumption baked into early architectural decisions that the only callers would be trusted. That assumption was fine in 2023 when most vLLM deployments were researchers running models on-premises. It sits less comfortably now that vLLM powers customer-facing inference APIs and enterprise LLM platforms. The Langflow RCE campaigns and the OpenAI sandbox escapes from last week suggest the AI inference stack is getting serious attention from attackers. The whole space needs to close that gap systematically, not patch-by-patch.

What to do

Upgrade to vLLM 0.25.0 or later. If that is not immediately possible, put authentication in front of the API endpoint and restrict which clients can send multimodal requests. The security advisory with full technical details is at GHSA-mm38-5g96-7j6x.

More coverage of AI tool and inference framework vulnerabilities.

Related CVEs
  • [ HIGH ]CVE-2026-116177vLLM uncontrolled resource consumption via Nemotron-VL processor

Found this useful? Share it.