Quick answer
Direct answer
Risk scores
| CVSS metric | What it means |
|---|---|
| Attack vector (AV:N) | Network: reachable remotely |
| Attack complexity (AC:L) | Low complexity |
| Privileges required (PR:N) | No privileges required |
| User interaction (UI:R) | A user must take an action |
| Scope (S:U) | Scope unchanged |
| Confidentiality (C:H) | High confidentiality impact |
| Integrity (I:H) | High integrity impact |
| Availability (A:H) | High availability impact |
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
About Vllm
CVE-2026-22807 affects Vllm, a product from Vllm. Before acting, confirm where Vllm runs in your estate, who owns it and whether it is reachable from the internet, because exposure decides real risk more than the score alone.
What the flaw is
In plain terms: 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.
The weakness class is Code Injection. Attacker input is executed as program code.
Based on its CVSS vector, the flaw can be reached over the network, needs no login, and relies on a user taking an action. Apply the vendor fix and confirm exposure on internet facing and business critical assets first.
Affected versions and timeline
| Field | Detail |
|---|---|
| Product | Vllm |
| Affected versions | Vllm from 0.10.1 before 0.14.0 |
| Published | Jan 21, 2026 |
| Last modified | Jul 21, 2026 |
| Added to CISA KEV | Not listed |
| Assigning CNA | security-advisories@github.com |
How to detect it
- Inventory every instance of Vllm and record the running version against the affected range above.
- Check external attack surface scans for internet facing instances of the component.
- Review logs on affected systems for unusual requests, errors or new processes around the vulnerable function.
- Confirm with an authenticated vulnerability scan once your scanner has a check for this CVE.
How to fix it
- Apply the fixed version of Vllm named in the vendor advisory.
- If patching must wait, restrict network access to the affected service and put it behind authentication or a web application firewall rule.
- Rescan after the change to prove the exposure is gone, then close the ticket.
CTEM action plan
| CTEM stage | What to do for this CVE |
|---|---|
| Scope | Add every business service that depends on Vllm to the current CTEM cycle. |
| Discover | Find all instances, including shadow and cloud deployments, and record versions and exposure. |
| Prioritize | Rank using EPSS and CVSS together with asset exposure and business impact. |
| Validate | Confirm the flaw is reachable and exploitable in your environment and that compensating controls work. |
| Mobilize | Assign the fix to the asset owner with a due date matched to the priority, then verify closure. |
CWE References
- CWE-94: Code Injection More CVEs with this weakness
- CWE-94: Code Injection More CVEs with this weakness
Technical References
- ▸NVD entry
- ▸CVE.org record
- ▸Fix commit on GitHub
- ▸GitHub issue or pull request
- ▸GitHub repository reference
- ▸GitHub Security Advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
- ▸Red Hat security advisory
Frequently asked questions
Related CVEs
vLLM versions 0.22.0 through 0.23.0 fail to validate stop_token_ids against vocabulary bounds in Rust HTTP and gRPC frontends, allowing out-of-vocabulary token IDs to reach MinTokensLogitsProcessor. Attackers can submit requests with min_tokens greater than zero and out-of-vocabulary stop_token_ids to trigger CUDA tensor indexing failures that leave EngineCore in a fatal state requiring service restart.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, the structured_outputs.regex API parameter passes a user-supplied regular expression string directly to the grammar compiler backends with no compilation timeout; in the xgrammar backend the string reaches the regex compiler with no guard, and in the outlines backend the validation step blocks structural issues such as lookarounds and backreferences but performs no complexity analysis, so a pattern with nested quantifiers passes all checks and causes exponential state-space expansion, allowing a single request containing an adversarial regex to hang an inference worker indefinitely and deny service. This issue is fixed in version 0.24.0.
vLLM versions >= 0.10.2 and < 0.13.0 are missing sparse tensor validation in multimodal embeddings processing. Because PyTorch disables sparse tensor invariant checks by default, an attacker can submit crafted embedding requests with malformed (negative or out-of-bounds) tensor indices, when the prompt-embeds feature is enabled, to trigger crashes or resource exhaustion (denial of service), with potential for out-of-bounds/write-what-where memory corruption. This continues CVE-2025-62164, whose prior fix only disabled the feature by default rather than addressing the root cause.
vLLM is an inference and serving engine for large language models (LLMs). The SSRF protection fix for CVE-2026-24779 add in 0.15.1 can be bypassed in the load_from_url_async method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client. The SSRF fix uses urllib3.util.parse_url() to validate and extract the hostname from user-provided URLs. However, load_from_url_async uses aiohttp for making the actual HTTP requests, and aiohttp internally uses the yarl library for URL parsing. This vulnerability in 0.17.0.
Autel Maxi Charger Single firmware through V1.03.51 allows unauthenticated remote code execution via the service listening on TCP port 9002. A crafted request to the /test endpoint can cause the device to download, extract, and execute attacker-controlled files with root privileges.
Erugo is a self-hosted file-sharing platform. In versions up to and including 0.2.14, an authenticated low-privileged user can upload arbitrary files to any specified location due to insufficient validation of user‑supplied paths when creating shares. By specifying a writable path within the public web root, an attacker can upload and execute arbitrary code on the server, resulting in remote code execution (RCE). This vulnerability allows a low-privileged user to fully compromise the affected Erugo instance. Version 0.2.15 fixes the issue.
Earn your free CTEM certification.
Learn to scope, prioritize, validate and mobilize fixes for CVEs like CVE-2026-22807 with a free CTEM certification.
Beginner / Practitioner / Program Leader
Explore certifications