CVE-2026-27893: vLLM trust_remote_code bypass enables

Q: Is CVE-2026-27893 actively exploited?

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

Q: How to fix CVE-2026-27893?

1. PATCH: Upgrade to vLLM 0.18.0 — this is the only complete fix. 2. IMMEDIATE WORKAROUND: Restrict model sources to internally-mirrored, verified repositories only. Block direct HuggingFace or external S3 model loading until patched. 3. AUDIT: Inventory all vLLM instances across environments (dev, staging, prod); check version with `pip show vllm`. 4. DETECT: Review recent model load events in vLLM logs for external model sources; flag any models loaded from outside your approved registry. 5. HARDEN: Implement model signing and hash verification before loading any model artifact, regardless of vLLM version. 6. ISOLATE: Run vLLM inference processes with minimum necessary permissions and network segmentation to limit blast radius if exploited.

Q: What systems are affected by CVE-2026-27893?

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, model evaluation pipelines, multi-model serving platforms, fine-tuning pipelines, model-as-a-service APIs.

Q: What is the CVSS score for CVE-2026-27893?

CVE-2026-27893 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 1.36%.

CISO Take

If your team runs vLLM 0.10.1–0.17.x with --trust-remote-code=False, that control is silently ignored for certain model sub-components — you have a false sense of security. Any malicious model loaded from an external repository (HuggingFace, S3, etc.) can execute arbitrary code on your inference server. Upgrade to vLLM 0.18.0 immediately; until patched, restrict model loading strictly to internally-hosted, verified artifacts.

What is the risk?

High operational risk for AI/ML teams running vLLM in production or staging environments. The core danger is the security theater: operators who explicitly set --trust-remote-code=False believe they are protected — they are not. EPSS (0.00032) suggests no active exploitation yet, but the attack requires only a convincing malicious model repository and a standard model-loading workflow. Organizations loading third-party or community models are directly in the blast radius. CVSS 8.8 reflects accurate severity: network-reachable, low complexity, full C/I/A impact once triggered.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	>= 0.10.1, < 0.18.0	`0.18.0`
84.6K 130 dependents Pushed 6d ago 23% patched ~51d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

1.4%

chance of exploitation in 30 days

Higher than 68% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

6 steps

PATCH

Upgrade to vLLM 0.18.0 — this is the only complete fix.
IMMEDIATE WORKAROUND

Restrict model sources to internally-mirrored, verified repositories only. Block direct HuggingFace or external S3 model loading until patched.
AUDIT

Inventory all vLLM instances across environments (dev, staging, prod); check version with pip show vllm.
DETECT

Review recent model load events in vLLM logs for external model sources; flag any models loaded from outside your approved registry.
HARDEN

Implement model signing and hash verification before loading any model artifact, regardless of vLLM version.
ISOLATE

Run vLLM inference processes with minimum necessary permissions and network segmentation to limit blast radius if exploited.

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?

Code Execution Supply Chain Inference Framework Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0058 - Publish Poisoned Models AML.T0072 - Reverse Shell

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system

ISO 42001

A.6.1.4 - AI system security A.9.1 - AI supply chain management

NIST AI RMF

MANAGE 2.2 - Mechanisms are in place to sustain AI risk management

OWASP LLM Top 10

LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-27893?

If your team runs vLLM 0.10.1–0.17.x with --trust-remote-code=False, that control is silently ignored for certain model sub-components — you have a false sense of security. Any malicious model loaded from an external repository (HuggingFace, S3, etc.) can execute arbitrary code on your inference server. Upgrade to vLLM 0.18.0 immediately; until patched, restrict model loading strictly to internally-hosted, verified artifacts.

Is CVE-2026-27893 actively exploited?

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

How to fix CVE-2026-27893?

1. PATCH: Upgrade to vLLM 0.18.0 — this is the only complete fix. 2. IMMEDIATE WORKAROUND: Restrict model sources to internally-mirrored, verified repositories only. Block direct HuggingFace or external S3 model loading until patched. 3. AUDIT: Inventory all vLLM instances across environments (dev, staging, prod); check version with `pip show vllm`. 4. DETECT: Review recent model load events in vLLM logs for external model sources; flag any models loaded from outside your approved registry. 5. HARDEN: Implement model signing and hash verification before loading any model artifact, regardless of vLLM version. 6. ISOLATE: Run vLLM inference processes with minimum necessary permissions and network segmentation to limit blast radius if exploited.

What systems are affected by CVE-2026-27893?

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, model evaluation pipelines, multi-model serving platforms, fine-tuning pipelines, model-as-a-service APIs.

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

CVE-2026-27893 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 1.36%.

What is the AI security impact?

Affected AI Architectures

LLM inference servingmodel evaluation pipelinesmulti-model serving platformsfine-tuning pipelinesmodel-as-a-service APIs

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0058 Publish Poisoned Models

AML.T0072 Reverse Shell

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: A.6.1.4, A.9.1

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM03:2025

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.18.0, 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. Version 0.18.0 patches the issue.

Exploitation Scenario

An adversary publishes a seemingly legitimate LLM variant on HuggingFace — a fine-tuned model with a slightly modified architecture requiring custom code. The model's custom Python files contain a reverse shell or credential harvester. A data science team evaluating the model runs vLLM with --trust-remote-code=False, confident the security control protects them. During model loading, vLLM internally calls load_pretrained on sub-components using hardcoded trust_remote_code=True, bypassing the user flag. The malicious Python code executes in the context of the inference server process, giving the adversary RCE with access to model weights, inference traffic, internal APIs, and potentially cloud credentials mounted in the environment.

Weaknesses (CWE)

CWE-693 Protection Mechanism Failure Primary CWE-693 Protection Mechanism Failure Primary CWE-693 Protection Mechanism Failure

CWE-693 — Protection Mechanism Failure: The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

Source: MITRE CWE corpus.