CVE-2026-90553

Executive Summary

CVE-2026-90553 is a remote code execution vulnerability in vLLM versions prior to 0.28.0, residing in the LlavaOnevision2 processor loader. The loader fails to honor the trust_remote_code parameter when instantiating remote processor classes, allowing arbitrary Python code embedded in a model's processing_llava_onevision2.py file to execute with the privileges of the vLLM process — even when trust_remote_code=False is explicitly set. Any organization running vulnerable vLLM instances and loading third-party or untrusted multimodal models is affected; successful exploitation yields full confidentiality, integrity, and availability impact (CVSS 7.8) under the assumption of user interaction (loading a crafted model).

Technical Analysis

vLLM is a high-throughput inference and serving engine for large language models. It supports a wide range of multimodal architectures, including LLaVA-OneVision-style processors. Processor classes define tokenization, image preprocessing, and input assembly for these multimodal models. To support non-core model architectures, vLLM — like the broader Hugging Face transformers ecosystem — offers a trust_remote_code mechanism: when enabled, Python modules shipped alongside a model repository are imported and executed as part of the model-loading pipeline.

The core defect here is a logic bypass of a security control. The LlavaOnevision2 processor loader is documented (per the NVD description) to respect the trust_remote_code parameter. In practice, it does not: when resolving the remote processor class, it imports and instantiates classes from a repository-supplied module — specifically processing_llava_onevision2.py — regardless of whether trust_remote_code is False. Because Python import semantics execute top-level module code at import time, any statements placed at module scope, class-body scope, or within a class constructor/__init__ that is invoked during processor instantiation will run with the vLLM process's OS-level authority.

This vulnerability class — unsafe deserialization/code loading via a trusted-configuration flag that is silently ignored — is a recurring anti-pattern in ML tooling. It is distinct from generic deserialization (e.g., pickle) because the trigger is a module import, not a data stream. The security boundary that vLLM intends to enforce is: "if the operator has not opted in via trust_remote_code=True, third-party model code must not execute." CVE-2026-90553 breaks that boundary for one specific processor path.

Key technical properties derivable from the description:

• Attack surface: model loading / processor instantiation for the LLaVA-OneVision2 architecture.
• Trigger artifact: a crafted repository containing a malicious processing_llava_onevision2.py.
• Control being bypassed: the trust_remote_code parameter.
• Execution context: the vLLM process's authority (no privilege boundary crossed; impact equals the privileges under which vLLM runs).
• Attack vector (CVSS): Local (AV:L) with User Interaction required (UI:R) — consistent with an operator or automated pipeline loading a model that the attacker has supplied or poisoned.

No function names, argument signatures, or call paths beyond those stated in the description are asserted here. The exact mechanism by which the loader "ignores" trust_remote_code (e.g., missing conditional branch, hard-coded True, or an alternate import path) is not specified in the available data and should not be assumed.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available. The attack chain below is inferred strictly from the vulnerability class and the NVD description; no specific code patterns or hypothetical function names are invented.

1. Reconnaissance / target identification. The attacker identifies a target running a vLLM deployment at a version earlier than 0.28.0 that supports the LLaVA-OneVision2 architecture. Such deployments are typically inference servers, internal R&D clusters, or SaaS platforms hosting third-party models. Because exploitation is Local (AV:L) and requires user interaction (UI:R), the realistic vector is model supply-chain poisoning or social engineering — the attacker does not need network access to the vLLM service itself, only the ability to get a crafted model loaded by the victim.

2. Delivery of a malicious model. The attacker publishes or provides a model repository that includes a processing_llava_onevision2.py file containing arbitrary code. This may be hosted on a public model hub, shared as a tar/zip artifact, delivered via an internal model registry, or shipped as part of a dependency. The repository is configured to select the LLaVA-OneVision2 processor path so the vulnerable loader is exercised.

3. Trigger of the flaw class. An operator, or an automated pipeline, attempts to load the model. Critically, the operator may set trust_remote_code=False, believing third-party code will not run. Because the LlavaOnevision2 processor loader ignores this flag, it imports the remote processor module and instantiates the processor class. Python import semantics execute the attacker-supplied code at that point. This is a code-injection / unsafe-code-loading trigger — the attacker's payload is the module body and/or processor class definition, not a data payload.

4. Execution and post-exploitation impact. The code executes with the authority of the vLLM process. Because vLLM inference servers are commonly run with access to GPU resources, model caches, credentials for model hubs, and network reachability to internal services, post-exploitation could include: environment and credential theft, lateral movement to model registries or adjacent services, persistence via modification of cached models or startup scripts, data exfiltration of prompts and outputs, and resource abuse (cryptomining on GPU hosts). The CVSS vector reflects high impact to confidentiality, integrity, and availability, with scope unchanged — the blast radius is bounded by the privileges and network position of the vLLM process, not by a further privilege escalation.

Impact Assessment

• CVSS 3.1 Base Score: 7.8 (High). Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.

  • AV:L (Local) — the attacker is not exploiting a network-facing endpoint directly; the trigger is a model artifact loaded locally by the victim.
  • AC:L (Low) — no specialized conditions beyond loading the crafted model.
  • PR:N (No privileges required) — the attacker needs no account on the target system.
  • UI:R (User Interaction Required) — a user (or automated loader) must load the malicious model.
  • S:U (Scope Unchanged) — impact stays within the vLLM process's security authority.
  • C:H / I:H / A:H — full compromise of confidentiality, integrity, and availability for the affected component.

• Affected systems: any deployment running vLLM < 0.28.0 that loads models via the LLaVA-OneVision2 processor path. Multimodal inference clusters, model-serving APIs, CI/CD pipelines that validate or convert models, and research environments are all plausible.

• Blast radius: bounded by the privileges of the vLLM process but potentially severe in practice. GPU nodes frequently hold cloud credentials, model-hub tokens, and network access to internal artifact stores. A single compromised model load can pivot into model-registry tampering and broader infrastructure compromise.

• EPSS: Not yet scored by FIRST.org. Do not assume a low or high likelihood; prioritize based on exposure to untrusted model sources.

Detection Guidance

Detection for this class of vulnerability is challenging because exploitation occurs during a legitimate-looking model load, and the malicious artifact is a Python module. Layered detection — process telemetry, file integrity monitoring, network egress, and YARA scanning of model repositories — provides the best coverage.

Sigma Rule

title: Suspicious Python Execution During vLLM Model Load (LlavaOnevision2 Processor)
id: 3f8c1b2a-9d4e-4a7b-b6c1-0e2f7a9d4c55
status: experimental
description: Detects child processes spawned by a vLLM process during model loading, consistent with code execution via a malicious processing_llava_onevision2.py module (CVE-2026-90553).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-90553
author: valtersit.com Threat Intelligence
date: 2026-01-01
tags:
  - attack.t1195
  - attack.t1059
  - cve.2026-90553
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/python'
      - '/python3'
      - '/vllm'
      - '/vllm.entrypoints'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/chmod'
  selection_ctx:
    CommandLine|contains:
      - 'processing_llava_onevision2'
      - 'llava_onevision2'
      - 'trust_remote_code'
      - 'load_model'
  condition: selection_parent and selection_child and selection_ctx
falsepositives:
  - Legitimate model preprocessing scripts that shell out to system utilities
  - Framework plugins that spawn helper processes
level: high

YARA Rule

rule CVE_2026_90553_vLLM_LlavaOnevision2_Malicious_Processor
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects suspicious content in processing_llava_onevision2.py modules that may abuse CVE-2026-90553 to achieve code execution despite trust_remote_code=False."
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-90553"
        date = "2026-01-01"
        tlp = "WHITE"

    strings:
        $fname = "processing_llava_onevision2" ascii nocase

        $import1 = "import os" ascii
        $import2 = "import subprocess" ascii
        $import3 = "import socket" ascii
        $import4 = "import base64" ascii
        $import5 = "from os import" ascii

        $exec1 = "subprocess.Popen" ascii
        $exec2 = "subprocess.run" ascii
        $exec3 = "os.system" ascii
        $exec4 = "os.popen" ascii
        $exec5 = "eval(" ascii
        $exec6 = "exec(" ascii
        $exec7 = "__import__(" ascii
        $exec8 = "pty.spawn" ascii

        $net1 = "socket.socket" ascii
        $net2 = "urllib.request" ascii
        $net3 = "requests.get" ascii
        $net4 = "requests.post" ascii
        $net5 = "/dev/tcp/" ascii

        $b64_1 = "base64.b64decode" ascii
        $b64_2 = "codecs.decode" ascii

        $class = "class LlavaOnevision2" ascii nocase

    condition:
        (
            ($fname or $class)
            and 2 of ($exec*)
            and 1 of ($import*)
        )
        or
        (
            ($fname or $class)
            and 2 of ($exec*)
            and 1 of ($net*)
        )
        or
        (
            ($fname or $class)
            and 1 of ($exec*)
            and 2 of ($b64_*)
        )
}

Suricata IDS Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2026-90553 vLLM Model Fetch - LlavaOnevision2 Processor Module Download"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"processing_llava_onevision2.py"; nocase; classtype:attempted-user; reference:cve,2026-90553; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-90553; sid:9000001; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2026-90553 Possible Post-Exploitation Callback From vLLM Host"; flow:established,to_server; content:"|0d 0a|"; depth:2; dsize:>200; threshold:type limit, track by_src, count 1, seconds 300; classtype:trojan-activity; reference:cve,2026-90553; sid:9000002; rev:1;)

Note: the first rule targets HTTP retrieval of the specifically named module. The second is a coarse heuristic for callback traffic from vLLM hosts; tune $HOME_NET/port scoping to your environment.

Elastic Detection

process where event.type == "start" and
  process.parent.name in ("python", "python3", "vllm") and
  (
    process.command_line : "*processing_llava_onevision2*" or
    process.command_line : "*llava_onevision2*" or
    process.command_line : "*trust_remote_code*"
  ) and
  process.name in ("sh", "bash", "curl", "wget", "nc", "ncat", "python", "python3", "chmod", "base64")

file where event.action in ("creation", "modification") and
  file.name : "processing_llava_onevision2.py" and
  file.path : ("*cache*" or "*models*" or "*hub*")

Splunk SPL Query

index=endpoint OR index=linux (sourcetype=sysmon:linux OR sourcetype=auditd OR sourcetype=linux_secure)
(process_name=python OR process_name=python3 OR process_name=vllm OR Image="*python*")
| eval cmd=coalesce(CommandLine, process, cmdline)
| where like(cmd, "%processing_llava_onevision2%") OR like(cmd, "%llava_onevision2%")
   OR (like(cmd, "%trust_remote_code%") AND match(cmd, "(curl|wget|bash|sh |nc |ncat|base64|subprocess|os\.system|os\.popen)"))
| stats count min(_time) as first_seen max(_time) as last_seen values(cmd) as commands by host, user, parent_process_name
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="vllm,cve-2026-90553,">
  <rule id="100553" level="12">
    <decoded_as>json</decoded_as>
    <field name="audit.key">vllm-processor-load</field>
    <description>CVE-2026-90553: vLLM loaded LlavaOnevision2 processor module while trust_remote_code disabled</description>
    <mitre>
      <id>T1195</id>
      <id>T1059</id>
    </mitre>
  </rule>

  <rule id="100554" level="14">
    <if_sid>100553</if_sid>
    <field name="audit.exe">python|python3|bash|sh|curl|wget|nc</field>
    <description>CVE-2026-90553: Suspicious child process spawned during vLLM LlavaOnevision2 model load</description>
    <mitre>
      <id>T1059</id>
    </mitre>
  </rule>

  <rule id="100555" level="10">
    <decoded_as>syscheck</decoded_as>
    <field name="file">processing_llava_onevision2.py</field>
    <description>CVE-2026-90553: Modified/created LLavaOnevision2 processor module in model cache directory</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED — no patch evidence from any tracked source. No vendor advisory, commit, release note, or workaround has been identified. Although the NVD description states "vLLM before 0.28.0," which implies 0.28.0 contains a fix, this must be verified directly with the vendor. Do not assume remediation until confirmed.

1) Immediate mitigations (compensating controls):

• Do not load untrusted models. Restrict model loading to a curated, internally vetted allowlist hosted on a controlled registry. This is the single most effective mitigation because the vulnerability is only reachable via a crafted model repository.
• Air-gap / network-restrict vLLM hosts. Prevent outbound access to public model hubs from production inference nodes; fetch models via an internal proxy that scans artifacts.
• Scan model repositories before load. Apply the YARA rule above to all processing_llava_onevision2.py and related processor modules. Reject artifacts containing dynamic execution, network, or subprocess primitives.
• Run vLLM with least privilege. Drop capabilities, use a dedicated low-privilege service account, isolate GPU nodes, and restrict access to model-hub tokens and cloud credentials in the process environment.
• File integrity monitoring. Alert on creation/modification of processing_llava_onevision2.py in model cache and download directories.

2) Patch / upgrade steps:

• Monitor the vLLM release notes and security advisories for a fix referencing CVE-2026-90553 or the LlavaOnevision2 processor loader's trust_remote_code handling.
• Once a fix is released, upgrade vLLM to the patched version (presumptively 0.28.0 or later per the NVD description — verify), and re-validate that the loader honors trust_remote_code=False in a staging environment before production rollout.
• If no fix is available, treat every model as untrusted and enforce mitigations in step 1.

3) Long-term hardening:

• Adopt a supply-chain policy that requires signing and provenance (e.g., SLSA/Sigstore) for all model artifacts and their code modules.
• Implement pre-load static analysis in CI for all model code paths that can execute Python (processors, custom modules, remote code).
• Audit vLLM and framework configuration to ensure trust_remote_code defaults to False and that no code path overrides it. Add regression tests asserting this invariant for every processor loader.
• Segment inference infrastructure from credential stores and internal control planes; use short-lived, scoped tokens for model hub access.

References

1. National Vulnerability Database — CVE-2026-90553: https://nvd.nist.gov/vuln/detail/CVE-2026-90553
2. vLLM project documentation and releases (verify patch status for 0.28.0): https://github.com/vllm-project/vllm
3. Hugging Face trust_remote_code security documentation (background on the bypassed control): https://huggingface.co/docs/transformers/security
4. MITRE ATT&CK T1195 — Supply Chain Compromise: https://attack.mitre.org/techniques/T1195/
5. CISA Known Exploited Vulnerabilities Catalog (not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild status: No public PoC, exploit code, or Nuclei template is available. CVE-2026-90553 is not listed in the CISA KEV catalog. No threat actor campaigns have been attributed. EPSS has not yet scored this CVE by FIRST.org. Given the model supply-chain attack vector, organizations should nonetheless prioritize the compensating controls above, as weaponization would typically occur through poisoned public model repositories.