vLLM
CVE-2026-22807
CRITICAL
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Remote malicious model gives AV:N and full C/I/A impact, but an operator must choose to load the untrusted model, so UI:R rather than UI:N.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
10Blast Radius
ecosystem impact- 1 pypi packages depend on vllm (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.10.1.
DescriptionNVD
vLLM is an inference and serving engine for large language models (LLMs). Starting in version 0.10.1 and prior to version 0.14.0, vLLM loads Hugging Face auto_map dynamic modules during model resolution without gating on trust_remote_code, allowing attacker-controlled Python code in a model repo/path to execute at server startup. 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. Version 0.14.0 fixes the issue.
AnalysisAI
Remote code execution in vLLM 0.10.1 through 0.13.x lets an attacker who controls the model repository or path run arbitrary Python on the inference host: vLLM auto-loads Hugging Face auto_map dynamic modules during model resolution without honoring the trust_remote_code safety gate, so attacker-supplied code executes at server startup before any request is processed and without API access. The flaw carries a CVSS 9.8 and is fixed in 0.14.0, with Red Hat shipping multiple RHSA errata; however EPSS is only 0.06% (17th percentile) and there is no public exploit identified at time of analysis, so exploitation hinges on an attacker first influencing which model is loaded. This is a code-injection (CWE-94) trust-boundary bypass rather than a remotely reachable network service bug despite the AV:N rating.
Technical ContextAI
vLLM is a high-throughput inference and serving engine for large language models and is the affected product per cpe:2.3:a:vllm:vllm. The defect lies in vLLM's model-resolution path, which mirrors Hugging Face Transformers' custom-architecture mechanism: a model repo can declare an auto_map in its config pointing to custom Python modules (modeling/tokenizer code) that the framework imports dynamically. Hugging Face guards this with trust_remote_code, which must be explicitly enabled before remote/custom code is executed. vLLM failed to apply that gate, importing the auto_map dynamic modules unconditionally during model load. The root cause class is CWE-94 (Improper Control of Generation of Code / code injection): untrusted data (a model repo's config and bundled Python) is turned into executed code without an authorization check, collapsing the trust boundary between 'load a model' and 'run arbitrary code as the server process.'
RemediationAI
Primary fix: upgrade to vLLM 0.14.0 or later (Vendor-released patch: 0.14.0), which restores gating of auto_map dynamic-module loading behind trust_remote_code; the fix is in commit 78d13ea9de4b1ce5e4d8a5af9738fea71fb024e5 and PR https://github.com/vllm-project/vllm/pull/32194, released as https://github.com/vllm-project/vllm/releases/tag/v0.14.0. Red Hat users should apply the corresponding errata (e.g. RHSA-2026:3461/3462/3713/3782/5119 and later). Until patched, the most effective compensating control is to load only models from trusted, integrity-verified sources and never point vLLM at remote or user-supplied Hugging Face repos/local directories - treat the model path as a code-execution input; trade-off: this blocks dynamic-model workflows. Additionally, run vLLM as an unprivileged, sandboxed/containerized user with no outbound network and read-only model storage so a malicious auto_map import cannot escalate or persist (trade-off: may break automated model pulls). Pin and review model configs (inspect for auto_map/custom code) in any pipeline that fetches models automatically. See GHSA-2pc9-4j83-qjmr for vendor guidance.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same weakness CWE-94 – Code Injection
View allSame technique Code Injection
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-2pc9-4j83-qjmr