External risk intelligence

vLLM RCE via Multimodal Processor Code Revision.

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-114053

The vulnerability exists in vLLM, a framework commonly deployed as an internet-facing API service for model inference. Because the flaw is reachable via the unauthenticated /tokenize endpoint, and such API endpoints are typically exposed to receive requests in standard production deployments, there is a clear path for public network reachability.

Code Injection

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in vLLM, a system for serving large language models, allows unauthenticated attackers to execute arbitrary code. This occurs when a specially crafted multimodal request is sent to the `/tokenize` endpoint, potentially compromising the API process.

Unauthenticated code execution flaw in vLLM.
Matters if you use vLLM for AI model inference.
Confirm relevance and scope of potential exposure.

Attack Path

How an attacker could exploit the issue

An attacker could target an unauthenticated `/tokenize` endpoint exposed by vLLM. By crafting a multimodal request that manipulates the `mm_processor_kwargs.code_revision` parameter, an attacker could trick the system into loading a malicious revision of the model's processor code. If `trust_remote_code` is enabled, this allows the attacker to execute arbitrary Python code within the vLLM API process.

No authentication required for entry.
Malicious `code_revision` in multimodal request.
Arbitrary Python code execution.

Live Threat

Current exploitation, exposure, and threat context

When `trust_remote_code` is enabled, an attacker could execute arbitrary Python code within the vLLM API process by crafting a multimodal request to the `/tokenize` endpoint. This occurs when a malicious revision of dynamic processor code is served from the model repository, allowing the attacker to control the code imported by the `Transformers AutoProcessor.from_pretrained` function.

Arbitrary code execution in API process.
Malicious model revision via multimodal request.
Compromise of vLLM API service.

Operational Fix

Recommended remediation, mitigation, and detection steps

Teams responsible for managing and securing AI inference platforms, including platform engineering and security operations, should lead the response. The first step is to inventory all vLLM deployments, determine their exposure to untrusted input, and identify business-critical instances to prioritize remediation efforts.

Platform or AI engineering teams own remediation.
Verify vLLM deployment reachability and criticality.
Plan risk-based updates or temporary mitigations.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is vLLM and how is it used?

vLLM is an open-source library designed for high-throughput, efficient serving of large language models (LLMs). It is commonly utilized by developers to deploy AI inference engines that provide model access through a web API, allowing applications to interact with language and multimodal models in production environments.

How does CVE-2026-114053 enable code execution?

This vulnerability is classified as CWE-94: Improper Control of Generation of Code. It occurs because vLLM insecurely passes user-provided parameters directly to the model loading process. When 'trust_remote_code' is enabled, an attacker can specify a malicious model processor revision, forcing the server to import and execute arbitrary, attacker-controlled Python code.

What triggers the vulnerability in vLLM?

The flaw is triggered when an attacker sends a specially crafted multimodal request to the unauthenticated /tokenize endpoint. It is important to note that the vulnerability does not manifest unless 'trust_remote_code' is explicitly enabled in the vLLM configuration, as this setting is required to allow the execution of dynamic processor code.

Why is this vLLM vulnerability relevant to my infrastructure?

Halo Surface Signal indicates that because vLLM is frequently deployed as an internet-facing API service, the /tokenize endpoint is often publicly reachable. If your instance is exposed to the internet, unauthorized actors can reach this endpoint without authentication, potentially leading to a full compromise of the API process.

How should I respond to this threat?

Begin by auditing your current deployments to identify which instances are running affected versions of vLLM and have 'trust_remote_code' enabled. Prioritize these for updates to a patched version. If an immediate update is not possible, evaluate if you can restrict network access to the /tokenize endpoint or disable remote code execution settings in your model configurations.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.