CVE-2026-22807: vLLM Code Injection enables RCE

CISO Take

If your organization runs vLLM between 0.10.1 and 0.13.x, patch to 0.14.0 immediately — this is a pre-auth RCE that fires at model load, before your WAF or API gateway sees a single packet. Any attacker who can influence which model your vLLM instance loads (via a malicious HuggingFace repo or poisoned local path) can own the inference host with zero friction. Audit your model sourcing pipeline and pin to verified checksums while patching.

What is the risk?

CRITICAL. CVSS 9.8 with zero prerequisites — no authentication, no user interaction, network-accessible — makes this as exploitable as it gets theoretically. The low EPSS (0.0002) reflects limited current in-the-wild activity, not the severity of potential impact. Organizations loading models from public HuggingFace repos without strict checksum validation are at highest risk. Blast radius is full host compromise of inference infrastructure, which in AI-heavy environments typically means GPU clusters, proprietary model weights, training data, and lateral movement into adjacent internal services.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
83.4K 130 dependents Pushed 2d ago 34% patched ~32d to patch Full package profile →
vLLM	pip	>= 0.10.1, < 0.14.0	`0.14.0`
83.4K 130 dependents Pushed 2d ago 34% patched ~32d to patch Full package profile →

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 41% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

6 steps

PATCH

Upgrade vLLM to >= 0.14.0 immediately — this is the only complete fix.
INTERIM WORKAROUND

Explicitly set trust_remote_code=False; audit all currently loaded model paths for auto_map keys in config.json files.
MODEL PROVENANCE

Implement SHA-256 checksum verification for all HuggingFace model downloads before serving; pin models to specific commit hashes rather than branch or tag references.
NETWORK ISOLATION

Route all model downloads through an approved internal registry or proxy — block direct vLLM-to-HuggingFace egress in production.
DETECTION

Alert on unexpected outbound connections from vLLM processes at startup; monitor for child processes spawned by vLLM during model load; review auto_map entries in all loaded model configs.
SUPPLY CHAIN

Enforce an approved model allowlist in production; prohibit ad-hoc model loading from user-specified paths.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain Code Execution Framework Inference Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0049 - Exploit Public-Facing Application AML.T0050 - Command and Scripting Interpreter AML.T0058 - Publish Poisoned Models AML.T0072 - Reverse Shell

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, robustness and cybersecurity Article 15 - Accuracy, Robustness and Cybersecurity Article 9 - Risk Management System

ISO 42001

A.6.2.3 - AI Supply Chain Management A.8.4 - AI System Supply Chain Management A.9.5 - AI System Security

NIST AI RMF

GOVERN 6.1 - AI Supply Chain Risk Management GOVERN-1.2 - Accountability Structures for AI Risk MANAGE-2.2 - Mechanisms to Address Identified AI Risks

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-22807?

If your organization runs vLLM between 0.10.1 and 0.13.x, patch to 0.14.0 immediately — this is a pre-auth RCE that fires at model load, before your WAF or API gateway sees a single packet. Any attacker who can influence which model your vLLM instance loads (via a malicious HuggingFace repo or poisoned local path) can own the inference host with zero friction. Audit your model sourcing pipeline and pin to verified checksums while patching.

Is CVE-2026-22807 actively exploited?

No confirmed active exploitation of CVE-2026-22807 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-22807?

1. PATCH: Upgrade vLLM to >= 0.14.0 immediately — this is the only complete fix. 2. INTERIM WORKAROUND: Explicitly set trust_remote_code=False; audit all currently loaded model paths for auto_map keys in config.json files. 3. MODEL PROVENANCE: Implement SHA-256 checksum verification for all HuggingFace model downloads before serving; pin models to specific commit hashes rather than branch or tag references. 4. NETWORK ISOLATION: Route all model downloads through an approved internal registry or proxy — block direct vLLM-to-HuggingFace egress in production. 5. DETECTION: Alert on unexpected outbound connections from vLLM processes at startup; monitor for child processes spawned by vLLM during model load; review auto_map entries in all loaded model configs. 6. SUPPLY CHAIN: Enforce an approved model allowlist in production; prohibit ad-hoc model loading from user-specified paths.

What systems are affected by CVE-2026-22807?

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, model serving, AI/ML CI/CD pipelines, model evaluation pipelines, multi-tenant AI platforms.

What is the CVSS score for CVE-2026-22807?

CVE-2026-22807 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.54%.

What is the AI security impact?

Affected AI Architectures

LLM inference servingmodel servingAI/ML CI/CD pipelinesmodel evaluation pipelinesmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

AML.T0058 Publish Poisoned Models

AML.T0072 Reverse Shell

Compliance Controls Affected

EU AI Act: Art.15, Article 15, Article 9

ISO 42001: A.6.2.3, A.8.4, A.9.5

NIST AI RMF: GOVERN 6.1, GOVERN-1.2, MANAGE-2.2

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An adversary creates a malicious model repository on HuggingFace and embeds a reverse shell or credential harvester in the auto_map field of the model's config.json as attacker-controlled Python code. The adversary engineers model adoption via social engineering targeting ML engineers ('try this fine-tuned model'), compromising an upstream model dependency, or gaining write access to a CI/CD pipeline configuration specifying model paths. When the unpatched vLLM instance initializes, it resolves and executes the auto_map module with vLLM process privileges — before serving any requests and before any API-layer security controls engage — achieving full host compromise. No vLLM API credentials are required, only influence over the model path.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection') Primary

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.