Vllm Project
Monthly
Uncontrolled memory allocation in vLLM's transcription endpoint before 0.28.0 allows authenticated API clients to crash the entire server process by submitting FLAC audio files with forged, inflated sample rate headers. Because vLLM commonly operates as a shared API server across multiple tenants, a single authenticated attacker can deny service to all concurrent users. VulnCheck reported this with a CVSS 4.0 score of 7.1; no public exploit code or CISA KEV listing has been identified at time of analysis.
Remote code execution in vLLM's LlavaOnevision2 processor loader allows an attacker who controls a model repository to execute arbitrary code on systems that load that model, bypassing the trust_remote_code=False safety parameter entirely. All vLLM installations prior to version 0.28.0 are affected when loading LlavaOnevision2-architecture models; the security control that operators rely on to safely evaluate third-party models is silently non-functional for this processor class. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the attack requires only the ability to publish a model to an accessible registry and social-engineer a user into loading it.
Denial of service in vLLM 0.12.0 through 0.23.x lets any authorized API caller crash the entire inference server by submitting a pure prompt-embeddings payload to the /v1/completions endpoint when a model using M-RoPE (multimodal rotary position embedding) is loaded. The malformed request trips a reachable assertion in the EngineCore process, which terminates the whole server rather than rejecting the single request. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in vLLM 0.24.0.
Denial of service in vLLM inference servers prior to 0.24.0 allows remote unauthenticated attackers to hang an inference worker indefinitely by submitting a single request with an adversarial regular expression via the structured_outputs.regex API parameter. The pattern is passed to grammar compiler backends (xgrammar with no guard, outlines with structural-but-not-complexity validation) where nested quantifiers trigger exponential state-space expansion (ReDoS). No public exploit identified at time of analysis, though the trivial request-based trigger makes weaponization straightforward.
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the shared engine worker by sending a specific multi-request speculative decoding workload. The rejection sampler produces a recovered token equal to the vocabulary-size boundary, which is coerced to -1, written back into the drafter's input ids, and later dereferenced by the embedding/attention path, triggering a GPU device-side assertion that kills the worker. There is no public exploit identified at time of analysis and this CVE is not in CISA KEV; per CVSS the impact is availability-only (C:N/I:N/A:H) with a low EPSS profile expected for a crash-only bug.
Remote code execution in vLLM versions prior to 0.22.1 allows attackers to backdoor production LLM inference deployments through a dependency confusion attack in the project's Dockerfile. Because flashinfer-jit-cache was pulled via --extra-index-url with UV_INDEX_STRATEGY=unsafe-best-match while the name remained unregistered on PyPI, any attacker who claimed the name on PyPI with a higher version would have their code executed as root during every Docker build. No public exploit identified at time of analysis, but the supply-chain primitive is well understood and trivially weaponizable.
Denial of service in vLLM 0.8.0 and later allows remote unauthenticated attackers to crash the inference server by sending a single OpenAI-compatible chat completion request containing a video/jpeg data URL with thousands of comma-separated base64-encoded JPEG frames. The VideoMediaIO.load_base64() method decodes every frame without enforcing a count limit, exhausting server memory. No public exploit identified at time of analysis, but an upstream fix commit is available on GitHub.
Remote code execution in vLLM 0.14.1 occurs because `trust_remote_code=True` is hardcoded inside the NemotronVL and KimiK25 model loaders, silently overriding the operator's explicit `--trust-remote-code=False` safety flag. Any deployment that loads a malicious or compromised HuggingFace repository for these model architectures will execute attacker-controlled Python in the inference process, despite UI:R requiring an operator to initiate the model load. No public exploit is identified at time of analysis, but the issue is an incomplete fix for CVE-2025-66448 and CVE-2026-22807, indicating the regression pattern is already well understood.
vLLM versions 0.5.5 through 0.17.x use incorrect mono audio downmixing via numpy.mean instead of the ITU-R BS.775-4 weighted standard, causing audio processed by AI models to diverge from human perception. An authenticated remote attacker with low privileges can exploit this inconsistency to manipulate audio-based model outputs or infer mismatches between expected and actual audio processing, affecting integrity of audio-driven inference pipelines. The vulnerability has been patched in vLLM 0.18.0.
Unbounded audio extraction in vLLM 0.10.2-0.27.x enables remote denial of service against NanoNemotronVL model deployments. The root cause is an asymmetric protection gap: `_extract_audio_from_videos` in `nano_nemotron_vl.py` calls `load_audio_pyav` without the size or duration guard parameters enforced on the direct audio upload path, bypassing the `VLLM_MAX_AUDIO_DECODE_DURATION_S` and `VLLM_MAX_AUDIO_DECODE_BYTES` environment variable limits entirely. An attacker submitting a maliciously compressed video via the multimodal inference API forces the server to allocate gigabytes of memory during audio decoding, crashing the service. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor-released patch is available in vLLM 0.28.0.
Remote denial-of-service in vLLM before 0.27.0 allows unauthenticated network attackers to activate the DeepStream GPU video-decode backend per-request, initialize the process-wide GPU decode pool, and submit video content that bypasses pixel-limit enforcement, causing partial availability loss for concurrent inference requests. The root cause is vLLM's failure to classify DeepStream as a GPU backend subject to resource controls combined with an omitted pixel-limit check in the DeepStream decode path (CWE-400). No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Server-side request forgery in vLLM's MiMoV2OmniMultiModalProcessor allows authenticated API users to bypass the framework's media access controls, enabling arbitrary file reads on the vLLM host and SSRF requests to internal network resources. The flaw affects all vLLM releases prior to 0.26.0 where attacker-controlled image and audio URL strings were passed directly to _fetch_image, requests.get, and Image.open instead of routing through the MediaConnector abstraction that enforces allowed_media_domains and allowed_local_media_path restrictions. No public exploit code or CISA KEV listing exists at time of analysis, but the low attack complexity and network-accessible vector make this a meaningful risk for deployments serving untrusted authenticated users via the affected multimodal processor.
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client to exhaust CPU, memory, async scheduling capacity, and engine request slots with a single crafted request. Affected versions span 0.19.0 through 0.25.x; the issue is fixed in 0.26.0. No public exploit code has been identified and CISA has not listed this in KEV, but the attack is trivially constructable by any client with a valid API credential.
Cross-user inference data leakage in vLLM prior to 0.27.0 exposes one batched user's prompt or completion output to another user sharing the same GPU inference batch. The root cause is a 32-bit integer overflow in the CUDA kernel `act_and_mul_kernel` within `activation_kernels.cu`, where the pointer arithmetic `blockIdx.x * 2 * d` wraps around when token indices and hidden-dimension sizes are large enough, redirecting the kernel to read from an adjacent user's input buffer. No active exploitation has been confirmed (no CISA KEV listing), but the vendor has patched the issue in v0.27.0 and a detailed GitHub advisory and PR diff are publicly available.
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant guard introduced for CVE-2025-62164, permitting an invalid sparse tensor to reach `tensor.to_dense()` and cause availability disruption. Affected deployments span versions 0.20.2rc0 through 0.25.x and are limited to instances with `enable_prompt_embeds` explicitly enabled. No public exploit code or CISA KEV listing exists at time of analysis; the fix is confirmed in v0.26.0.
Uncontrolled resource consumption in vLLM's lm-format-enforcer structured output backend (all versions prior to 0.26.0) enables unauthenticated remote denial of service via the /v1/completions API endpoint. By submitting a crafted catastrophically backtracking regular expression to the structured_outputs.regex parameter, a remote attacker can saturate an entire CPU core and stall the structured-output engine path indefinitely - blocking inference requests that rely on the lm-format-enforcer backend for all concurrent users. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, though the attack primitive (ReDoS against an exposed API) is well-understood and trivially constructible by any attacker familiar with catastrophic regex patterns.
Information disclosure in vLLM prior to version 0.26.0 leaks server filesystem internals - including OS usernames, home and virtual-environment directory paths, Python version, internal package structure, line numbers, and endpoint handler names - through HTTP error responses. Any unauthenticated network attacker can trigger this by sending malformed JSON to the OpenAI-compatible API endpoints, requiring zero privileges and no special configuration beyond a default vLLM deployment. No public exploit code has been identified at time of analysis, and no CISA KEV listing exists; however, the trivial exploitation bar (a single malformed HTTP request) and the reconnaissance value of the leaked data elevate real-world risk above the CVSS 5.3 score alone implies.
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by uploading arbitrarily large audio files. The `/v1/audio/transcriptions` and `/v1/audio/translations` endpoints invoke `request.file.read()` to fully buffer multipart uploads into process memory before the `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` size guard is evaluated, meaning the size limit is checked only after the damage is done. No public exploit is identified at time of analysis; vendor-confirmed fix is available in version 0.24.0.
Denial of service in vllm 0.19.0's OpenAI-compatible serving path allows remote unauthenticated attackers to exhaust scheduler resources by submitting requests with unbounded logprob counts. The root cause, confirmed by PR diff analysis, is the absence of any per-batch logprob budget in the v1 scheduler: requests specifying logprobs=-1 (full vocabulary) multiplied across parallel sequences (n) generate massive compute and memory overhead with no cap, blocking or crashing the inference server. Publicly available exploit code exists (GitHub issue #37343); no confirmed active exploitation at time of analysis.
vllm-project vllm version 0.6.0 contains a vulnerability in the AsyncEngineRPCServer() RPC server entrypoints. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Uncontrolled memory allocation in vLLM's transcription endpoint before 0.28.0 allows authenticated API clients to crash the entire server process by submitting FLAC audio files with forged, inflated sample rate headers. Because vLLM commonly operates as a shared API server across multiple tenants, a single authenticated attacker can deny service to all concurrent users. VulnCheck reported this with a CVSS 4.0 score of 7.1; no public exploit code or CISA KEV listing has been identified at time of analysis.
Remote code execution in vLLM's LlavaOnevision2 processor loader allows an attacker who controls a model repository to execute arbitrary code on systems that load that model, bypassing the trust_remote_code=False safety parameter entirely. All vLLM installations prior to version 0.28.0 are affected when loading LlavaOnevision2-architecture models; the security control that operators rely on to safely evaluate third-party models is silently non-functional for this processor class. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the attack requires only the ability to publish a model to an accessible registry and social-engineer a user into loading it.
Denial of service in vLLM 0.12.0 through 0.23.x lets any authorized API caller crash the entire inference server by submitting a pure prompt-embeddings payload to the /v1/completions endpoint when a model using M-RoPE (multimodal rotary position embedding) is loaded. The malformed request trips a reachable assertion in the EngineCore process, which terminates the whole server rather than rejecting the single request. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in vLLM 0.24.0.
Denial of service in vLLM inference servers prior to 0.24.0 allows remote unauthenticated attackers to hang an inference worker indefinitely by submitting a single request with an adversarial regular expression via the structured_outputs.regex API parameter. The pattern is passed to grammar compiler backends (xgrammar with no guard, outlines with structural-but-not-complexity validation) where nested quantifiers trigger exponential state-space expansion (ReDoS). No public exploit identified at time of analysis, though the trivial request-based trigger makes weaponization straightforward.
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the shared engine worker by sending a specific multi-request speculative decoding workload. The rejection sampler produces a recovered token equal to the vocabulary-size boundary, which is coerced to -1, written back into the drafter's input ids, and later dereferenced by the embedding/attention path, triggering a GPU device-side assertion that kills the worker. There is no public exploit identified at time of analysis and this CVE is not in CISA KEV; per CVSS the impact is availability-only (C:N/I:N/A:H) with a low EPSS profile expected for a crash-only bug.
Remote code execution in vLLM versions prior to 0.22.1 allows attackers to backdoor production LLM inference deployments through a dependency confusion attack in the project's Dockerfile. Because flashinfer-jit-cache was pulled via --extra-index-url with UV_INDEX_STRATEGY=unsafe-best-match while the name remained unregistered on PyPI, any attacker who claimed the name on PyPI with a higher version would have their code executed as root during every Docker build. No public exploit identified at time of analysis, but the supply-chain primitive is well understood and trivially weaponizable.
Denial of service in vLLM 0.8.0 and later allows remote unauthenticated attackers to crash the inference server by sending a single OpenAI-compatible chat completion request containing a video/jpeg data URL with thousands of comma-separated base64-encoded JPEG frames. The VideoMediaIO.load_base64() method decodes every frame without enforcing a count limit, exhausting server memory. No public exploit identified at time of analysis, but an upstream fix commit is available on GitHub.
Remote code execution in vLLM 0.14.1 occurs because `trust_remote_code=True` is hardcoded inside the NemotronVL and KimiK25 model loaders, silently overriding the operator's explicit `--trust-remote-code=False` safety flag. Any deployment that loads a malicious or compromised HuggingFace repository for these model architectures will execute attacker-controlled Python in the inference process, despite UI:R requiring an operator to initiate the model load. No public exploit is identified at time of analysis, but the issue is an incomplete fix for CVE-2025-66448 and CVE-2026-22807, indicating the regression pattern is already well understood.
vLLM versions 0.5.5 through 0.17.x use incorrect mono audio downmixing via numpy.mean instead of the ITU-R BS.775-4 weighted standard, causing audio processed by AI models to diverge from human perception. An authenticated remote attacker with low privileges can exploit this inconsistency to manipulate audio-based model outputs or infer mismatches between expected and actual audio processing, affecting integrity of audio-driven inference pipelines. The vulnerability has been patched in vLLM 0.18.0.
Unbounded audio extraction in vLLM 0.10.2-0.27.x enables remote denial of service against NanoNemotronVL model deployments. The root cause is an asymmetric protection gap: `_extract_audio_from_videos` in `nano_nemotron_vl.py` calls `load_audio_pyav` without the size or duration guard parameters enforced on the direct audio upload path, bypassing the `VLLM_MAX_AUDIO_DECODE_DURATION_S` and `VLLM_MAX_AUDIO_DECODE_BYTES` environment variable limits entirely. An attacker submitting a maliciously compressed video via the multimodal inference API forces the server to allocate gigabytes of memory during audio decoding, crashing the service. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor-released patch is available in vLLM 0.28.0.
Remote denial-of-service in vLLM before 0.27.0 allows unauthenticated network attackers to activate the DeepStream GPU video-decode backend per-request, initialize the process-wide GPU decode pool, and submit video content that bypasses pixel-limit enforcement, causing partial availability loss for concurrent inference requests. The root cause is vLLM's failure to classify DeepStream as a GPU backend subject to resource controls combined with an omitted pixel-limit check in the DeepStream decode path (CWE-400). No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Server-side request forgery in vLLM's MiMoV2OmniMultiModalProcessor allows authenticated API users to bypass the framework's media access controls, enabling arbitrary file reads on the vLLM host and SSRF requests to internal network resources. The flaw affects all vLLM releases prior to 0.26.0 where attacker-controlled image and audio URL strings were passed directly to _fetch_image, requests.get, and Image.open instead of routing through the MediaConnector abstraction that enforces allowed_media_domains and allowed_local_media_path restrictions. No public exploit code or CISA KEV listing exists at time of analysis, but the low attack complexity and network-accessible vector make this a meaningful risk for deployments serving untrusted authenticated users via the affected multimodal processor.
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client to exhaust CPU, memory, async scheduling capacity, and engine request slots with a single crafted request. Affected versions span 0.19.0 through 0.25.x; the issue is fixed in 0.26.0. No public exploit code has been identified and CISA has not listed this in KEV, but the attack is trivially constructable by any client with a valid API credential.
Cross-user inference data leakage in vLLM prior to 0.27.0 exposes one batched user's prompt or completion output to another user sharing the same GPU inference batch. The root cause is a 32-bit integer overflow in the CUDA kernel `act_and_mul_kernel` within `activation_kernels.cu`, where the pointer arithmetic `blockIdx.x * 2 * d` wraps around when token indices and hidden-dimension sizes are large enough, redirecting the kernel to read from an adjacent user's input buffer. No active exploitation has been confirmed (no CISA KEV listing), but the vendor has patched the issue in v0.27.0 and a detailed GitHub advisory and PR diff are publicly available.
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant guard introduced for CVE-2025-62164, permitting an invalid sparse tensor to reach `tensor.to_dense()` and cause availability disruption. Affected deployments span versions 0.20.2rc0 through 0.25.x and are limited to instances with `enable_prompt_embeds` explicitly enabled. No public exploit code or CISA KEV listing exists at time of analysis; the fix is confirmed in v0.26.0.
Uncontrolled resource consumption in vLLM's lm-format-enforcer structured output backend (all versions prior to 0.26.0) enables unauthenticated remote denial of service via the /v1/completions API endpoint. By submitting a crafted catastrophically backtracking regular expression to the structured_outputs.regex parameter, a remote attacker can saturate an entire CPU core and stall the structured-output engine path indefinitely - blocking inference requests that rely on the lm-format-enforcer backend for all concurrent users. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, though the attack primitive (ReDoS against an exposed API) is well-understood and trivially constructible by any attacker familiar with catastrophic regex patterns.
Information disclosure in vLLM prior to version 0.26.0 leaks server filesystem internals - including OS usernames, home and virtual-environment directory paths, Python version, internal package structure, line numbers, and endpoint handler names - through HTTP error responses. Any unauthenticated network attacker can trigger this by sending malformed JSON to the OpenAI-compatible API endpoints, requiring zero privileges and no special configuration beyond a default vLLM deployment. No public exploit code has been identified at time of analysis, and no CISA KEV listing exists; however, the trivial exploitation bar (a single malformed HTTP request) and the reconnaissance value of the leaked data elevate real-world risk above the CVSS 5.3 score alone implies.
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by uploading arbitrarily large audio files. The `/v1/audio/transcriptions` and `/v1/audio/translations` endpoints invoke `request.file.read()` to fully buffer multipart uploads into process memory before the `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` size guard is evaluated, meaning the size limit is checked only after the damage is done. No public exploit is identified at time of analysis; vendor-confirmed fix is available in version 0.24.0.
Denial of service in vllm 0.19.0's OpenAI-compatible serving path allows remote unauthenticated attackers to exhaust scheduler resources by submitting requests with unbounded logprob counts. The root cause, confirmed by PR diff analysis, is the absence of any per-batch logprob budget in the v1 scheduler: requests specifying logprobs=-1 (full vocabulary) multiplied across parallel sequences (n) generate massive compute and memory overhead with no cap, blocking or crashing the inference server. Publicly available exploit code exists (GitHub issue #37343); no confirmed active exploitation at time of analysis.
vllm-project vllm version 0.6.0 contains a vulnerability in the AsyncEngineRPCServer() RPC server entrypoints. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.