CVE-2025-66448
published 2025-12-01CVE-2025-66448: 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…
PriorityP355high8.8CVSS 3.1
AVNACLPRNUIRSUCHIHAH
EPSS
0.60%
44.1th percentile
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.
Affected
4 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| vllm-project | vllm-project_vllm | unspecified – latest | — |
| vllm | vllm | < 0.11.1 | 0.11.1 |
| vllm | vllm | >= 0 < 0.11.1 | 0.11.1 |
| vllm | vllm | >= 0.10.1 < 0.18.0 | 0.18.0 |
CVSS provenance
nvdv3.18.8HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
ghsa8.8HIGH
osv8.8HIGH
vendor_redhat7.1HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-g57c-wgqx-8wx7: vllm-project/vllm version 0
ghsa_unreviewed·2026-05-28·CVSS 8.8
CVE-2026-4944 [HIGH] CWE-22 GHSA-g57c-wgqx-8wx7: vllm-project/vllm version 0
vllm-project/vllm version 0.14.1 contains a vulnerability where the `trust_remote_code=True` parameter is hardcoded in two model implementation files (`vllm/model_executor/models/nemotron_vl.py` and `vllm/model_executor/models/kimi_k25.py`). This bypasses the user's explicit `--trust-remote-code=False` setting, enabling remote code execution via malicious HuggingFace model repositories. This issue is an incomplete fix for CVE-2025-66448 and CVE-2026-22807, as it affects separate code paths in model implementation files. Deployments loading NemotronVL or KimiK25 models are particularly impacted.
OSV
vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out
osv·2026-03-27·CVSS 8.8
CVE-2026-27893 [HIGH] vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out
vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out
### Summary
Two model implementation files hardcode `trust_remote_code=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/model_executor/models/nemotron_vl.py:430`
```python
vision_model = AutoModel.from_config(config.vision_config, trust_remote_code=True)
```
2. vllm/model_executor/models/kimi_k25.py:177
```python
cached_get_image_processor(self.ctx.model_config.model, trust_remote_code=True)
```
Both pass a hardcoded trust_remote_code=True to
GHSA
vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out
ghsa·2026-03-27·CVSS 8.8
CVE-2026-27893 [HIGH] CWE-693 vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out
vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out
### Summary
Two model implementation files hardcode `trust_remote_code=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/model_executor/models/nemotron_vl.py:430`
```python
vision_model = AutoModel.from_config(config.vision_config, trust_remote_code=True)
```
2. vllm/model_executor/models/kimi_k25.py:177
```python
cached_get_image_processor(self.ctx.model_config.model, trust_remote_code=True)
```
Both pass a hardcoded trust_remote_code=True to
GHSA
vLLM vulnerable to remote code execution via transformers_utils/get_config
ghsa·2025-12-02
CVE-2025-66448 [HIGH] CWE-94 vLLM vulnerable to remote code execution via transformers_utils/get_config
vLLM vulnerable to remote code execution via transformers_utils/get_config
### Summary
`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 silen
OSV
vLLM vulnerable to remote code execution via transformers_utils/get_config
osv·2025-12-02
CVE-2025-66448 [HIGH] vLLM vulnerable to remote code execution via transformers_utils/get_config
vLLM vulnerable to remote code execution via transformers_utils/get_config
### Summary
`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 silen
Red Hat
vllm: vLLM: Remote Code Execution via malicious model configuration
vendor_redhat·2025-12-01·CVSS 7.1
CVE-2025-66448 [HIGH] CWE-94 vllm: vLLM: Remote Code Execution via malicious model configuration
vllm: vLLM: Remote Code Execution via malicious model configuration
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 mali
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2025-12-01
Published