CVE-2025-66448
HighCVSS 7.1Exploitation Probability (EPSS)
Elevated risk51th percentile - higher than 51% of all known CVEs
Summary
vLLM, an inference and serving engine for large language models, prior to 0.11.1 has a critical remote code execution vector in the Nemotron_Nano_VL_Config config class. Loading a model config with an auto_map entry fetches and executes Python from a remote repository, even when trust_remote_code=False is set.
Risk Assessment
An attacker can publish a benign-looking frontend repo whose config points to a malicious backend repo, silently executing arbitrary code on the victim host.
Recommendation
Update vLLM to version 0.11.1 or later and exercise caution when loading models from untrusted repositories.
Other vulnerabilities in vLLM
See all- 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-115918Medium
vLLM from 0.16.0 until 0.32.0 allows an authenticated caller to place an attacker-controlled template in chat_template_kwargs[chat_template] when no server template is configured. ChatParams.get_apply_chat_template_kwargs() preserves that value without enforcing trust_request_chat_template, bypassing the trust policy and causing CPU or memory exhaustion through Jinja rendering.
- CVE-2026-115917Low
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, the OpenAI-compatible server configures Starlette CORSMiddleware with allowed_origins set to a wildcard by default. A malicious web page can use a victim's browser to reach an unauthenticated vLLM server on localhost, an internal network, or a VPN, call endpoints including GET /v1/models and POST /v1/chat/completions, consume GPU resources, and read responses. This issue is fixed in version 0.32.0.
- CVE-2026-115916Medium
vLLM before 0.32.0, in vllm/tokenizers/hf.py, computes max_token_id with an off-by-one upper bound, allowing a pre-tokenized prompt ID equal to the vocabulary size to pass validation. For tensor-parallel size one and an exact multiple-of-64 vocabulary, VocabParallelEmbedding.forward does not mask that value before F.embedding uses it, causing a CUDA device-side assertion and terminating the engine.
- CVE-2026-115915High
Prior to 0.32.0, vLLM's ImageMediaIO passes attacker-controlled image bytes to Pillow through Image.open(BytesIO(data)) without restricting decoder selection, and the MIME label does not constrain the selected format. Image-capable request paths through parse_image() and fetch_image() can dispatch an EPS payload to host components; a host with Ghostscript affected by CVE-2024-29510 can execute commands with the vLLM process's privileges, while Pillow 12.0.0 through 12.2.0 can trigger CVE-2026-59203 and exhaust media-loading workers.
- CVE-2026-115914Medium
vLLM from 0.11.1 until 0.32.0, in the DeepSeek-OCR, DeepSeek-OCR-2, and Unlimited-OCR image path, allows a remote client reaching the OpenAI-compatible API to submit a legal image whose normalized pixels sum to zero when alone in its per-step encoder batch. _parse_and_validate_image_input returns no embedding, embed_multimodal propagates that value, and sanity_check_mm_encoder_outputs triggers a fatal assertion that shuts down the engine for all users.
- CVE-2026-115913Medium
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, the Phi-4 multimodal audio encoder in phi4mm_audio.py and phi4mm_utils.py uses eager attention by default, allowing a remote client to submit one long audio clip that materializes full attention matrices and causes quadratic GPU-memory use, leading to out-of-memory and termination of EngineCore for all users.
- CVE-2026-115912High
Prior to 0.32.0, an authenticated caller in vLLM can place forged shared-memory address and monotonic_id values in public multimodal features.kwargs_data. In scale-out deployments with shared-memory multimodal caching enabled, workers trust those values and pass attacker-selected bytes to pickle.loads(), allowing arbitrary Python execution even when insecure serialization is disabled.
- CVE-2026-115911Medium
vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.32.0, authenticated callers can supply a chat template when no server-side --chat-template is configured, or a malicious model repository can provide a template compiled and rendered by tokenizer.apply_chat_template() without a wall-clock timeout, output-size limit, or iteration bound. Rendering runs in a ThreadPoolExecutor with one worker, so a nonterminating render can block /v1/responses and other chat-template users, while an output-expanding render can exhaust server memory.
Original NVD description (English source)
vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.11.1, vllm has a critical remote code execution vector in a config class named Nemotron_Nano_VL_Config. When vllm loads a model config that contains an auto_map entry, the config class resolves that mapping with get_class_from_dynamic_module(...) and immediately instantiates the returned class. This fetches and executes Python from the remote repository referenced in the auto_map string. Crucially, this happens even when the caller explicitly sets trust_remote_code=False in vllm.transformers_utils.config.get_config. In practice, an attacker can publish a benign-looking frontend repo whose config.json points via auto_map to a separate malicious backend repo; loading the frontend will silently run the backend’s code on the victim host. This vulnerability is fixed in 0.11.1.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

