CVE-2026-90553: vLLM RCE bypasses trust_remote_code

CISO Take

vLLM before 0.28.0 has a flaw in its LlavaOnevision2 processor loader that silently ignores the trust_remote_code=False setting, letting a malicious model's bundled Python file execute arbitrary code with the privileges of the vLLM process. This matters because trust_remote_code=False is the exact control security teams tell data scientists to rely on before loading third-party or community models, and here it does nothing — anyone pulling multimodal models from public hubs into a vLLM-based inference stack is exposed regardless of that setting. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so this isn't under active mass exploitation, but the bug is low-complexity to trigger (CVSS 7.8, AC:L, PR:N) and only needs a user to load a poisoned model. Patch to vLLM 0.28.0 or later immediately, and until then treat every model source as untrusted regardless of the trust_remote_code flag — enforce model provenance allowlists and run inference workloads in sandboxed/least-privilege containers. Detection teams should watch for unexpected child processes or network connections spawned by the vLLM service.

Sources: NVD GitHub Advisory ATLAS vulncheck.com

What is the risk?

High severity but currently low observed exploitation: CVSS 7.8 with local attack vector and required user interaction means an attacker cannot remotely trigger this without a victim first loading a crafted model, but once that happens the impact is complete (C/I/A all High) with no privileges required. The real danger is that it defeats the specific safeguard (trust_remote_code=False) organizations use to gate this exact risk class, so teams that believe they're protected are not. Absence of EPSS data, KEV listing, and public exploit code suggests exploitation is not yet weaponized at scale, but the vulnerability class (malicious code embedded in model artifacts) is well understood by attackers and trivially adaptable once a PoC surfaces.

How does the attack unfold?

Stage malicious model

Attacker publishes a model to a public repository bundled with a malicious processing_llava_onevision2.py containing arbitrary code.

AML.T0010.003

Victim loads model

An engineer loads the model into vLLM with trust_remote_code=False, believing that setting blocks unsafe custom code.

AML.T0011.000

Safeguard bypass and execution

vLLM's processor loader ignores the trust_remote_code flag for this class and executes the embedded malicious code.

AML.T0050

Host compromise

The attacker's code runs with vLLM process authority, granting code execution and access to any data or credentials on the inference host.

AML.T0112

Stage malicious model

Attacker publishes a model to a public repository bundled with a malicious processing_llava_onevision2.py containing arbitrary code.

AML.T0010.003

Victim loads model

An engineer loads the model into vLLM with trust_remote_code=False, believing that setting blocks unsafe custom code.

AML.T0011.000

Safeguard bypass and execution

vLLM's processor loader ignores the trust_remote_code flag for this class and executes the embedded malicious code.

AML.T0050

Host compromise

The attacker's code runs with vLLM process authority, granting code execution and access to any data or credentials on the inference host.

AML.T0112

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
91.6K 92 dependents Pushed 6d ago 27% patched ~49d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 11% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Upgrade vLLM to 0.28.0 or later immediately. 2) Do not rely on trust_remote_code=False as a security boundary for any model class until patched — treat it as broken. 3) Enforce a model provenance allowlist (only load models from vetted, signed, or internally-mirrored sources). 4) Run vLLM inference processes in sandboxed containers with least-privilege file system and network access to limit blast radius if code execution occurs. 5) Monitor for anomalous child processes, outbound connections, or file writes originating from the vLLM process as a detection signal. 6) Audit recent model loads for any LlavaOnevision2 or similar custom-processor models pulled from untrusted sources.

How is it classified?

Supply Chain Code Execution Inference Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0050 - Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2 - Third-party and supplier relationships for AI systems

NIST AI RMF

MAP-4 - Third-party AI system and component risks are mapped and managed

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-90553?

vLLM before 0.28.0 has a flaw in its LlavaOnevision2 processor loader that silently ignores the trust_remote_code=False setting, letting a malicious model's bundled Python file execute arbitrary code with the privileges of the vLLM process. This matters because trust_remote_code=False is the exact control security teams tell data scientists to rely on before loading third-party or community models, and here it does nothing — anyone pulling multimodal models from public hubs into a vLLM-based inference stack is exposed regardless of that setting. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so this isn't under active mass exploitation, but the bug is low-complexity to trigger (CVSS 7.8, AC:L, PR:N) and only needs a user to load a poisoned model. Patch to vLLM 0.28.0 or later immediately, and until then treat every model source as untrusted regardless of the trust_remote_code flag — enforce model provenance allowlists and run inference workloads in sandboxed/least-privilege containers. Detection teams should watch for unexpected child processes or network connections spawned by the vLLM service.

Is CVE-2026-90553 actively exploited?

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

How to fix CVE-2026-90553?

1) Upgrade vLLM to 0.28.0 or later immediately. 2) Do not rely on trust_remote_code=False as a security boundary for any model class until patched — treat it as broken. 3) Enforce a model provenance allowlist (only load models from vetted, signed, or internally-mirrored sources). 4) Run vLLM inference processes in sandboxed containers with least-privilege file system and network access to limit blast radius if code execution occurs. 5) Monitor for anomalous child processes, outbound connections, or file writes originating from the vLLM process as a detection signal. 6) Audit recent model loads for any LlavaOnevision2 or similar custom-processor models pulled from untrusted sources.

What systems are affected by CVE-2026-90553?

This vulnerability affects the following AI/ML architecture patterns: model serving, multimodal inference pipelines.

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

CVE-2026-90553 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.21%.

What is the AI security impact?

Affected AI Architectures

model servingmultimodal inference pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0050 Command and Scripting Interpreter

Compliance Controls Affected

ISO 42001: A.6.2

NIST AI RMF: MAP-4

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

vLLM before 0.28.0 contains a remote code execution vulnerability in the LlavaOnevision2 processor loader that ignores the trust_remote_code parameter when loading remote processor classes. Attackers can craft a malicious model with arbitrary code in processing_llava_onevision2.py that executes with vLLM process authority even when trust_remote_code is set to False.

Exploitation Scenario

An attacker publishes a seemingly legitimate multimodal model to a public model hub, bundling a malicious processing_llava_onevision2.py file containing a reverse shell or credential-stealing payload. A victim ML engineer discovers the model, and — following standard practice — loads it into vLLM with trust_remote_code=False, believing this prevents any custom code from executing. Because vLLM's processor loader ignores that flag for this processor class, the malicious code runs anyway with the full privileges of the vLLM process, giving the attacker code execution on the inference host, access to any co-located secrets or data, and a foothold to pivot further into the environment.

Weaknesses (CWE)

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

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.