Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
89 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A vulnerability was found in vLLM up to 0.19.0. The affected element is the function hasmambalayers of the file vllm/v1/kvcacheinterface.py of the component KV Block Handler. Performing a manipulation results in uninitialized resource. It is possible to initiate the attack remotely. The attack is considered to have high complexity. The exploitability is described as difficult. The exploit has been made public and could be used. The patch is named 1ad67864c0c20f167929e64c875f5c28e1aad9fd. To fix this issue, it is recommended to deploy a patch.
Recommended action: Upgrade to 0.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The VideoMediaIO.loadbase64() method at vllm/multimodal/media/video.py:51-62 splits video/jpeg data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The numframes parameter (default: 32), which is enforced by the loadbytes() code path at line 47-48, is completely bypassed in the video/jpeg base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. Details Vulnerable code The loadbytes() path (line 47-48) properly delegates to a video loader that respects self.numframes (default 32). The loadbase64("video/jpeg", ...) path bypasses this limit entirely — data.split(",") produces an unbounded list and every frame is decoded into a numpy array. video/jpeg is part of vLLM's public API video/jpeg is a vLLM-specific MIME type, not IANA-registered. However it is part of the public API surface: -…
Recommended action: Upgrade to 0.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server Side Request Forgery (SSRF) vulnerability in downloadbytesfromurl allows any actor who can control batch input JSON to make the vLLM batch runner issue arbitrary HTTP/HTTPS requests from the server, without any URL validation or domain restrictions. This can be used to target internal services (e.g. cloud metadata endpoints or internal HTTP APIs) reachable from the vLLM host. ------ Details Vulnerable component The vulnerable logic is in the batch runner entrypoint vllm/entrypoints/openai/runbatch.py, function downloadbytesfromurl: Key properties: - The function only parses the URL to dispatch on the scheme (data, http, https). - For http / https, it directly calls session.get(url) on the provided string. - There is no validation of: - hostname or IP address, - whether the target is internal or external, - port number, - path, query, or redirect target. - This is in contrast to the multimodal media path (MediaConnector), which implements an explicit domain allowlist.…
Recommended action: Upgrade to 0.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Denial of Service vulnerability exists in the vLLM OpenAI-compatible API server. Due to the lack of an upper bound validation on the n parameter in the ChatCompletionRequest and CompletionRequest Pydantic models, an unauthenticated attacker can send a single HTTP request with an astronomically large n value. This completely blocks the Python asyncio event loop and causes immediate Out-Of-Memory crashes by allocating millions of request object copies in the heap before the request even reaches the scheduling queue. Details The root cause of this vulnerability lies in the missing upper bound checks across the request parsing and asynchronous scheduling layers: 1. Protocol Layer: In vllm/entrypoints/openai/chatcompletion/protocol.py, the n parameter is defined simply as an integer without any pydantic.Field constraints for an upper bound. 1. SamplingParams Layer (Incomplete Validation): When the API request is converted to internal SamplingParams in vllm/samplingparams.py, the…
Recommended action: Upgrade to 0.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Two model implementation files hardcode trustremotecode=True when loading sub-components, bypassing the user's explicit --trust-remote-code=False security opt-out. This enables remote code execution via malicious model repositories even when the user has explicitly disabled remote code trust. Details Affected files (latest main branch): 1. vllm/modelexecutor/models/nemotronvl.py:430 2. vllm/modelexecutor/models/kimik25.py:177 Both pass a hardcoded trustremotecode=True to HuggingFace API calls, overriding the user's global --trust-remote-code=False setting. Relation to prior CVEs: - CVE-2025-66448 fixed automap resolution in vllm/transformersutils/config.py (config loading path) - CVE-2026-22807 fixed broader automap at startup - Both fixes are present in the current code. These hardcoded instances in model files survived both patches — different code paths. Impact Remote code execution. An attacker can craft a malicious model repository that executes arbitrary Python code…
Recommended action: Upgrade to 0.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSRF protection fix for https://github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc can be bypassed in the loadfromurlasync method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client. Affected Component - File: vllm/connections.py - Function: loadfromurlasync Vulnerability Details Root Cause The SSRF fix uses urllib3.util.parseurl() to validate and extract the hostname from user-provided URLs. However, loadfromurlasync uses aiohttp for making the actual HTTP requests, and aiohttp internally uses the yarl library for URL parsing. These two URL parsers handle backslash characters (\) differently: | Parser | Input URL | Parsed Host | Parsed Path | Behavior | |--------|-----------|-------------|-------------|----------| | urllib3.parseurl() | https://httpbin.org\@evil.com/ | httpbin.org | /%5C@evil.com/ | URL-encodes \ as %5C, treats \@evil.com/ as part of the path | | yarl (via aiohttp) |…
Recommended action: Upgrade to 0.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A chain of vulnerabilities in vLLM allow Remote Code Execution (RCE): 1. Info Leak - PIL error messages expose memory addresses, bypassing ASLR 2. Heap Overflow - JPEG2000 decoder in OpenCV/FFmpeg has a heap overflow that lets us hijack code execution Result: Send a malicious video URL to vLLM Completions or Invocations for a video model - Execute arbitrary commands on the server Completely default vLLM instance directly from pip, or docker, does not have authentication so "None" privileges are required, but even with non-default api-key enabled configuration this exploit is feasible through invocations route that allows payload to execute pre-auth. Example heap target is provided, other heap targets can be exploited as well to achieve rce. Leak allows for simple ASLR bypass. Leak + heap overflow achieves RCE on versions prior to 0.14.1. Deployments not serving a video model are not affected. --- 1. Vulnerability Overview 1.1 The Bug: JPEG2000 cdef Box Heap Overflow The…
Recommended action: Upgrade to 0.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in the MediaConnector class within the vLLM project's multimodal feature set. The loadfromurl and loadfromurlasync methods obtain and process media from URLs provided by users, using different Python parsing libraries when restricting the target host. These two parsing libraries have different interpretations of backslashes, which allows the host name restriction to be bypassed. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources. This vulnerability is particularly critical in containerized environments like llm-d, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause Denial of Service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal llm-d management endpoint, leading to system instability by falsely reporting metrics like the KV…
Recommended action: Upgrade to 0.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM loads Hugging Face automap dynamic modules during model resolution without gating on trustremotecode, allowing attacker-controlled Python code in a model repo/path to execute at server startup. --- Impact An attacker who can influence the model repo/path (local directory or remote Hugging Face repo) can achieve arbitrary code execution on the vLLM host during model load. This happens before any request handling and does not require API access. --- Affected Versions All versions where vllm/modelexecutor/models/registry.py resolves automap entries with trygetclassfromdynamicmodule without checking trustremotecode (at least current main). --- Details During model resolution, vLLM unconditionally iterates automap entries from the model config and calls trygetclassfromdynamicmodule, which delegates to Transformers’ getclassfromdynamicmodule and executes the module code. This occurs even when trustremotecode is false, allowing a malicious model repo to embed code in a…
Recommended action: Upgrade to 0.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Users can crash the vLLM engine serving multimodal models that use the Idefics3 vision model implementation by sending a specially crafted 1x1 pixel image. This causes a tensor dimension mismatch that results in an unhandled runtime error, leading to complete server termination. Details The vulnerability is triggered when the image processor encounters a 1x1 pixel image with shape (1, 1, 3) in HWC (Height, Width, Channel) format. Due to the ambiguous dimensions, the processor incorrectly assumes the image is in CHW (Channel, Height, Width) format with shape (3, H, W). This misinterpretation causes an incorrect calculation of the number of image patches, resulting in a fatal tensor split operation failure. Crash location: vllm/modelexecutor/models/idefics3.py line 672: The split() call fails because the computed numpatches value (17) does not match the actual tensor dimension (9): This unhandled exception terminates the EngineCore process, crashing the server. Affected Models…
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix here for CVE-2025-62164 is not sufficient. The fix only disables prompt embeds by default rather than addressing the root cause, so the DoS vulnerability remains when the feature is enabled. Details vLLM's pending change attempts to fix the root cause, which is the missing sparse tensor validation. PyTorch (~v2.0) disables sparse tensor validation (specifically, sparse tensor invariants checks) by default for performance reasons. vLLM is adding the sparse tensor validation to ensure indices are valid, non-negative, and within bounds. These checks help catch malformed tensors. PoC NA Impact Current fix only added a flag to disable/enable prompt embeds, so by default, prompt embeds feature is disabled in vLLM, which stops DoS attacks through the embeddings. However, It doesn’t address the problem when the flag is enabled and there is still potential for DoS attacks. Changes https://github.com/vllm-project/vllm/pull/30649
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vllm has a critical remote code execution vector in a config class named NemotronNanoVLConfig. When vllm loads a model config that contains an automap entry, the config class resolves that mapping with getclassfromdynamicmodule(...) and immediately instantiates the returned class. This fetches and executes Python from the remote repository referenced in the automap string. Crucially, this happens even when the caller explicitly sets trustremotecode=False in vllm.transformersutils.config.getconfig. In practice, an attacker can publish a benign-looking frontend repo whose config.json points via automap to a separate malicious backend repo; loading the frontend will silently run the backend’s code on the victim host. Details The vulnerable code resolves and instantiates classes from automap entries without checking whether those entries point to a different repo or whether remote code execution is allowed. getclassfromdynamicmodule(...) is capable of fetching and importing code…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /v1/chat/completions and /tokenize endpoints allow a chattemplatekwargs request parameter that is used in the code before it is properly validated against the chat template. With the right chattemplatekwargs parameters, it is possible to block processing of the API server for long periods of time, delaying all other requests Details In servingengine.py, the chattemplatekwargs are unpacked into kwargs passed to chatutils.py applyhfchattemplate with no validation on the keys or values in that chattemplatekwargs dict. This means they can be used to override optional parameters in the applyhfchattemplate method, such as tokenize, changing its default from False to True. https://github.com/vllm-project/vllm/blob/2a6dc67eb520ddb9c4138d8b35ed6fe6226997fb/vllm/entrypoints/openai/servingengine.py#L809-L814 https://github.com/vllm-project/vllm/blob/2a6dc67eb520ddb9c4138d8b35ed6fe6226997fb/vllm/entrypoints/chatutils.py#L1602-L1610 Both servingchat.py and servingtokenization.py call…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Users can crash the vLLM engine serving multimodal models by passing multimodal embedding inputs with correct ndim but incorrect shape (e.g. hidden dimension is wrong), regardless of whether the model is intended to support such inputs (as defined in the Supported Models page). The issue has existed ever since we added support for image embedding inputs, i.e. #6613 (released in v0.5.5) Details Using image embeddings as an example: - For models that support image embedding inputs, the engine crashes when scattering the embeddings to inputsembeds (mismatched shape) - For models that don't support image embedding inputs, the engine crashes when validating the inputs inside getinputembeddings (validation fails). This happens because we only validate ndim of the tensor, but not the full shape, in input processor (via MultiModalDataParser). Impact - Denial of service by crashing the engine Mitigation - Use API key to limit access to trusted users. - Set --limit-mm-per-prompt to 0…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A memory corruption vulnerability that leading to a crash (denial-of-service) and potentially remote code execution (RCE) exists in vLLM versions 0.10.2 and later, in the Completions API endpoint. When processing user-supplied prompt embeddings, the endpoint loads serialized tensors using torch.load() without sufficient validation. Due to a change introduced in PyTorch 2.8.0, sparse tensor integrity checks are disabled by default. As a result, maliciously crafted tensors can bypass internal bounds checks and trigger an out-of-bounds memory write during the call to todense(). This memory corruption can crash vLLM and potentially lead to code execution on the server hosting vLLM. Details A vulnerability that can lead to RCE from the completions API endpoint exists in vllm, where due to missing checks when loading user-provided tensors, an out-of-bounds write can be triggered. This happens because the default behavior of torch.load(tensor, weightsonly=True) since pytorch 2.8.0…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in the MediaConnector class within the vLLM project's multimodal feature set. The loadfromurl and loadfromurlasync methods fetch and process media from user-provided URLs without adequate restrictions on the target hosts. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources. This vulnerability is particularly critical in containerized environments like llm-d, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal llm-d management endpoint, leading to system instability by falsely reporting metrics like the KV cache state. Vulnerability Details The core of the vulnerability lies in the MediaConnector.loadfromurl method and its asynchronous counterpart. These methods…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A resource-exhaustion (denial-of-service) vulnerability exists in multiple endpoints of the OpenAI-Compatible Server due to the ability to specify Jinja templates via the chattemplate and chattemplatekwargs parameters. If an attacker can supply these parameters to the API, they can cause a service outage by exhausting CPU and/or memory resources. Details When using an LLM as a chat model, the conversation history must be rendered into a text input for the model. In hf/transformer, this rendering is performed using a Jinja template. The OpenAI-Compatible Server launched by vllm serve exposes a chattemplate parameter that lets users specify that template. In addition, the server accepts a chattemplatekwargs parameter to pass extra keyword arguments to the rendering function. Because Jinja templates support programming-language-like constructs (loops, nested iterations, etc.), a crafted template can consume extremely large amounts of CPU and memory and thereby trigger a…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The API key support in vLLM performed validation using a method that was vulnerable to a timing attack. This could potentially allow an attacker to discover a valid API key using an approach more efficient than brute force. Details https://github.com/vllm-project/vllm/blob/4b946d693e0af15740e9ca9c0e059d5f333b1083/vllm/entrypoints/openai/apiserver.py#L1270-L1274 API key validation used a string comparison that will take longer the more characters the provided API key gets correct. Data analysis across many attempts can allow an attacker to determine when it finds the next correct character in the key sequence. Impact Deployments relying on vLLM's built-in API key validation are vulnerable to authentication bypass using this technique.
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unsafe deserialization vulnerability allows any authenticated user to execute arbitrary code on the server if they are able to get the model to pass the code as an argument to a tool call. Details vLLM's Qwen3 Coder tool parser contains a code execution path that uses Python's eval() function to parse tool call parameters. This occurs during the parameter conversion process when the parser attempts to handle unknown data types. This code path is reached when: 1. Tool calling is enabled (--enable-auto-tool-choice) 2. The qwen3coder parser is specified (--tool-call-parser qwen3coder) 3. The parameter type is not explicitly defined or recognized Impact Remote Code Execution via Python's eval() function.
Recommended action: Upgrade to 0.10.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Denial of Service (DoS) vulnerability can be triggered by sending a single HTTP GET request with an extremely large header to an HTTP endpoint. This results in server memory exhaustion, potentially leading to a crash or unresponsiveness. The attack does not require authentication, making it exploitable by any remote user. Details The vulnerability leverages the abuse of HTTP headers. By setting a header such as X-Forwarded-For to a very large value like ("A" 5800000000), the server's HTTP parser or application logic may attempt to load the entire request into memory, overwhelming system resources. Impact What kind of vulnerability is it? Who is impacted? Type of vulnerability: Denial of Service (DoS) Resolution Upgrade to a version of vLLM that includes appropriate HTTP limits by deafult, or use a proxy in front of vLLM which provides protection against this issue.
Recommended action: Upgrade to 0.10.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The vLLM backend used with the /v1/chat/completions OpenAPI endpoint fails to validate unexpected or malformed input in the "pattern" and "type" fields when the tools functionality is invoked. These inputs are not validated before being compiled or parsed, causing a crash of the inference worker with a single request. The worker will remain down until it is restarted. Details The "type" field is expected to be one of: "string", "number", "object", "boolean", "array", or "null". Supplying any other value will cause the worker to crash with the following error: RuntimeError: [11:03:34] /project/cpp/jsonschemaconverter.cc:637: Unsupported type "somethingornothing" The "pattern" field undergoes Jinja2 rendering (I think) prior to being passed unsafely into the native regex compiler without validation or escaping. This allows malformed expressions to reach the underlying C++ regex engine, resulting in fatal errors. For example, the following inputs will crash the worker: Unclosed…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A denial of service bug caused the vLLM server to crash if an invalid regex was provided while using structured output. This vulnerability is similar to GHSA-6qc9-v4r8-22xg, but for regex instead of a JSON schema. Issue with more details: https://github.com/vllm-project/vllm/issues/17313 Patches https://github.com/vllm-project/vllm/pull/17623
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Hitting the /v1/completions API with a invalid jsonschema as a Guided Param will kill the vllm server Details The following API call (venv) [derekh@ip-172-31-15-108 ]$ curl -s http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Llama-3.2-3B-Instruct","prompt": "Name two great reasons to visit Sligo ", "maxtokens": 10, "temperature": 0.5, "guidedjson":"{\"properties\":{\"reason\":{\"type\": \"stsring\"}}}"}' will provoke a Uncaught exceptions from xgrammer in ./lib64/python3.11/site-packages/xgrammar/compiler.py Issue with more information: https://github.com/vllm-project/vllm/issues/17248 PoC Make a call to vllm with invalid jsonscema e.g. {\"properties\":{\"reason\":{\"type\": \"stsring\"}}} curl -s http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Llama-3.2-3B-Instruct","prompt": "Name two great reasons to visit Sligo ", "maxtokens": 10, "temperature": 0.5,…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the file vllm/multimodal/hasher.py, the MultiModalHasher class has a security and data integrity issue in its image hashing method. Currently, it serializes PIL.Image.Image objects using only obj.tobytes(), which returns only the raw pixel data, without including metadata such as the image’s shape (width, height, mode). As a result, two images of different sizes (e.g., 30x100 and 100x30) with the same pixel byte sequence could generate the same hash value. This may lead to hash collisions, incorrect cache hits, and even data leakage or security risks. Details - Affected file: vllm/multimodal/hasher.py - Affected method: MultiModalHasher.serializeitem https://github.com/vllm-project/vllm/blob/9420a1fc30af1a632bbc2c66eb8668f3af41f026/vllm/multimodal/hasher.py#L34-L35 - Current behavior: For Image.Image instances, only obj.tobytes() is used for hashing. - Problem description: obj.tobytes() does not include the image’s width, height, or mode metadata. - Impact: Two images with…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This issue arises from the prefix caching mechanism, which may expose the system to a timing side-channel attack. Description When a new prompt is processed, if the PageAttention mechanism finds a matching prefix chunk, the prefill process speeds up, which is reflected in the TTFT (Time to First Token). Our tests revealed that the timing differences caused by matching chunks are significant enough to be recognized and exploited. For instance, if the victim has submitted a sensitive prompt or if a valuable system prompt has been cached, an attacker sharing the same backend could attempt to guess the victim's input. By measuring the TTFT based on prefix matches, the attacker could verify if their guess is correct, leading to potential leakage of private information. Unlike token-by-token sharing mechanisms, vLLM’s chunk-based approach (PageAttention) processes tokens in larger units (chunks). In our tests, with chunksize=2, the timing differences became noticeable enough to allow…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.