CVE-2026-24779
HighCVSS 7.1Exploitation Probability (EPSS)
Low risk41th percentile - higher than 41% of all known CVEs
Summary
In vLLM prior to version 0.14.1, an SSRF vulnerability exists in the MediaConnector class. The load_from_url and load_from_url_async methods fetch media from user-supplied URLs, and different parsing libraries interpret backslashes differently, allowing bypass of host restrictions.
Risk Assessment
An attacker can force the vLLM server to make arbitrary requests to internal network resources. In containerized environments like llm-d, this enables network scanning, interaction with other pods, and potential denial of service or access to sensitive data.
Recommendation
Upgrade vLLM to version 0.14.1 or later, which contains a fix for this vulnerability.
Other vulnerabilities in vLLM
See all- CVE-2026-73558Medium
In vLLM prior to 0.27.0, an integer overflow in blockIdx.x * 2 * d in activation_kernels.cu can cause act_and_mul_kernel to consume another batched user's input, allowing a request processed in the same inference batch to receive a partial or complete copy of another user's inference result. This issue is fixed in version 0.27.0.
- CVE-2026-48746Critical
Vulnerability in vLLM versions 0.3.0 to 0.22.0 allows bypass of OpenAI API AuthenticationMiddleware. An attacker can use the API without providing the configured VLLM_API_KEY or --api-key.
- CVE-2026-22778Critical
A vulnerability in vLLM from version 0.8.3 to 0.14.0 leaks a heap address when an invalid image is sent to the multimodal endpoint. This leak reduces ASLR effectiveness from 4 billion to about 8 guesses, facilitating further attacks.
- CVE-2026-37237High
vLLM up to and including 0.17.0 allows remote attackers to cause a Denial of Service via memory exhaustion. The AsyncMediaIO.fetch_audio and AsyncMediaIO.fetch_image functions in multimodal/inputs.py fetch user-supplied media URLs using aiohttp and call r.read() without enforcing a maximum response size, allowing an attacker to exhaust server memory by providing a URL to an arbitrarily large file.
- CVE-2026-78684Medium
vLLM before 0.27.0 fails to properly classify DeepStream as a GPU backend and omits pixel-limit enforcement in its decode path. Unauthenticated attackers can activate DeepStream at request time to initialize the process-wide GPU decode pool and submit video that bypasses resource controls, causing partial denial of service for concurrent requests.
- CVE-2026-73560Medium
vLLM prior to 0.26.0 in the MiMoV2OmniMultiModalProcessor passes attacker-controlled image and audio strings through _fetch_image, requests.get, and Image.open instead of MediaConnector, bypassing allowed_media_domains and allowed_local_media_path protections. This allows server-side requests and reads of arbitrary files accessible to the vLLM process.
- CVE-2026-71486Medium
vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the /v1/completions/derender and /v1/chat/completions/derender endpoints accept caller-supplied GenerateResponse objects whose generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts structures are processed by OnlineDerenderer and tokenizer.decode before max_model_len, max_tokens, max_num_seqs, or response-size limits are enforced, allowing an authenticated API client to consume excessive CPU and memory and produce oversized responses. This issue is fixed in version 0.26.0.
- CVE-2026-73559Medium
vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.26.0, the prompt field in CompletionRequest in /v1/completions accepts an unbounded list of strings or ints, and functions prompt_to_seq() and OnlineRenderer.preprocess_completion() expand every element, causing the server to create one engine generator and response slot per prompt. An authenticated API client can exhaust CPU, memory, async scheduling capacity, engine request slots, and response buffering with one request. This issue is fixed in version 0.26.0.
- CVE-2026-73557Medium
In vLLM from 0.20.2rc0 until 0.26.0, safe_load_prompt_embeds in vllm/renderers/embed_utils.py uses torch.sparse.check_sparse_tensor_invariants, whose process-global save, enable, and restore state can be raced by concurrent prompt_embeds parts submitted to POST /v1/chat/completions through AsyncMultiModalItemTracker.resolve_items, asyncio.gather, and the default executor, allowing an invalid sparse tensor to reach tensor.to_dense despite the CVE-2025-62164 guard when enable_prompt_embeds is enabled. This issue is fixed in version 0.26.0.
- CVE-2026-73556Medium
In vLLM prior to 0.26.0, the structured_outputs.regex parameter in vllm/v1/structured_output/backend_lm_format_enforcer.py is passed to lmformatenforcer.RegexParser without compile_regex_with_timeout or validation in validate_structured_output_request_lm_format_enforcer, allowing an unauthenticated /v1/completions request against the lm-format-enforcer backend to consume a CPU core and stall the structured-output engine path with a catastrophic regular expression. This issue is fixed in version 0.26.0.
Original NVD description (English source)
vLLM is an inference and serving engine for large language models (LLMs). Prior to version 0.14.1, a Server-Side Request Forgery (SSRF) vulnerability exists in the `MediaConnector` class within the vLLM project's multimodal feature set. The load_from_url and load_from_url_async 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 cache state. Version 0.14.1 contains a patch for the issue.