CVE-2026-114053: Transformers RCE via code_revision

Q: Is CVE-2026-114053 actively exploited?

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

Q: How to fix CVE-2026-114053?

1) Upgrade vLLM to 0.31.0 or later (fix in commit 570735520942b6428ae98f1eb442c6d88adae55e; see GHSA-h3rc-6mm3-gc2m). 2) Where patching is delayed, disable trust_remote_code or serve only models whose processor code you have reviewed. 3) Pin model revisions to immutable commit hashes and mirror vetted models to an internal registry you control. 4) Never expose vLLM directly to the internet; require authentication (API key, mTLS, or an authenticating reverse proxy) and block /tokenize from untrusted clients. 5) Run the inference process with least privilege, in a container with restricted egress and no unnecessary secrets. 6) Detect by logging requests containing mm_processor_kwargs or code_revision, and alerting on unexpected hub downloads, new Python module loads from the Hugging Face modules cache, or unexpected child processes and outbound connections from the vLLM process.

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

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, multimodal inference pipelines, self-hosted OpenAI-compatible API endpoints.

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

CVE-2026-114053 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.46%.

CISO Take

vLLM versions 0.7.3 through 0.30.x forward a client-supplied mm_processor_kwargs.code_revision to Transformers' AutoProcessor.from_pretrained, so a remote caller can choose which revision of a model repository's dynamic processor code gets imported when trust_remote_code is enabled. The result is arbitrary Python execution inside the vLLM API process, reachable through the unauthenticated /tokenize endpoint. Exploitation is rated high complexity (CVSS 8.1) because the attacker must also control a revision in the served model's repository and the deployment must run with trust_remote_code. There is no public exploit, no Nuclei template, no KEV listing, and no EPSS score yet, so likelihood is currently unquantified rather than low. Upgrade to vLLM 0.31.0 or later, and in the meantime put authentication in front of the API and avoid trust_remote_code on models whose repositories are not fully under your control.

Sources:NVDGitHub AdvisoryVulnCheckATLAS

What is the risk?

High severity, with exposure-dependent likelihood. Impact is full compromise of the inference process (confidentiality, integrity, availability all high). Exploitability is limited by two preconditions: trust_remote_code must be enabled, and the attacker must control a revision (branch, tag, or commit) in the model repository the server loads. Servers exposed to untrusted networks without an authenticating gateway are most at risk, since /tokenize requires no credentials. Repositories on public hubs where third parties can open pull-request refs or hold write access raise the likelihood. No active exploitation or public PoC is known at publication, and EPSS data is unavailable.

How does the attack unfold?

Initial Access

Attacker sends a multimodal request with a crafted code_revision to the unauthenticated /tokenize endpoint.

AML.T0049

Malicious Code Load

vLLM passes the revision to AutoProcessor.from_pretrained, which fetches and imports attacker-controlled processor code.

AML.T0010.003

Execution

The imported Python runs inside the vLLM API process with its privileges.

AML.T0050

Impact

Attacker steals model weights and credentials, pivots internally, or disrupts inference service.

Initial Access

Attacker sends a multimodal request with a crafted code_revision to the unauthenticated /tokenize endpoint.

AML.T0049

Malicious Code Load

vLLM passes the revision to AutoProcessor.from_pretrained, which fetches and imports attacker-controlled processor code.

AML.T0010.003

Execution

The imported Python runs inside the vLLM API process with its privileges.

AML.T0050

Impact

Attacker steals model weights and credentials, pivots internally, or disrupts inference service.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Transformers	pip	—	No patch
168.1KOpenSSF 6.69.7K dependentsPushed 7d ago42% patched~89d to patchFull package profile →
vLLM	pip	>= 0.7.3, < 0.31.0	`0.31.0`
95.4K94 dependentsPushed 6d ago27% patched~37d to patchFull package profile →

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 40% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACHigh

PRNone

UINone

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade vLLM to 0.31.0 or later (fix in commit 570735520942b6428ae98f1eb442c6d88adae55e; see GHSA-h3rc-6mm3-gc2m). 2) Where patching is delayed, disable trust_remote_code or serve only models whose processor code you have reviewed. 3) Pin model revisions to immutable commit hashes and mirror vetted models to an internal registry you control. 4) Never expose vLLM directly to the internet; require authentication (API key, mTLS, or an authenticating reverse proxy) and block /tokenize from untrusted clients. 5) Run the inference process with least privilege, in a container with restricted egress and no unnecessary secrets. 6) Detect by logging requests containing mm_processor_kwargs or code_revision, and alerting on unexpected hub downloads, new Python module loads from the Hugging Face modules cache, or unexpected child processes and outbound connections from the vLLM process.

How is it classified?

Code ExecutionSupply ChainInferenceAPIModelAML.T0010.003- Model AML.T0049- Exploit Public-Facing Application AML.T0050- Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

MANAGE 2.3-Responses to unknown or emergent risks and vulnerabilities

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-114053?

vLLM versions 0.7.3 through 0.30.x forward a client-supplied mm_processor_kwargs.code_revision to Transformers' AutoProcessor.from_pretrained, so a remote caller can choose which revision of a model repository's dynamic processor code gets imported when trust_remote_code is enabled. The result is arbitrary Python execution inside the vLLM API process, reachable through the unauthenticated /tokenize endpoint. Exploitation is rated high complexity (CVSS 8.1) because the attacker must also control a revision in the served model's repository and the deployment must run with trust_remote_code. There is no public exploit, no Nuclei template, no KEV listing, and no EPSS score yet, so likelihood is currently unquantified rather than low. Upgrade to vLLM 0.31.0 or later, and in the meantime put authentication in front of the API and avoid trust_remote_code on models whose repositories are not fully under your control.

Is CVE-2026-114053 actively exploited?

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

How to fix CVE-2026-114053?

1) Upgrade vLLM to 0.31.0 or later (fix in commit 570735520942b6428ae98f1eb442c6d88adae55e; see GHSA-h3rc-6mm3-gc2m). 2) Where patching is delayed, disable trust_remote_code or serve only models whose processor code you have reviewed. 3) Pin model revisions to immutable commit hashes and mirror vetted models to an internal registry you control. 4) Never expose vLLM directly to the internet; require authentication (API key, mTLS, or an authenticating reverse proxy) and block /tokenize from untrusted clients. 5) Run the inference process with least privilege, in a container with restricted egress and no unnecessary secrets. 6) Detect by logging requests containing mm_processor_kwargs or code_revision, and alerting on unexpected hub downloads, new Python module loads from the Hugging Face modules cache, or unexpected child processes and outbound connections from the vLLM process.

What systems are affected by CVE-2026-114053?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, multimodal inference pipelines, self-hosted OpenAI-compatible API endpoints.

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

CVE-2026-114053 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.46%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference serversmultimodal inference pipelinesself-hosted OpenAI-compatible API endpoints

MITRE ATLAS Techniques

AML.T0010.003Model

AML.T0049Exploit Public-Facing Application

AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code is enabled. An attacker controlling a revision in the served model repository can send a multimodal request to the unauthenticated /tokenize endpoint to execute arbitrary Python in the vLLM API process.

Exploitation Scenario

An attacker identifies an internet-reachable vLLM server running a multimodal model with trust_remote_code enabled. They push or obtain a malicious revision of the model's processor code in the repository it is served from (for example through a compromised maintainer account, a writable branch, or an unmerged ref). They then send a multimodal request to /tokenize with mm_processor_kwargs.code_revision pointing at that revision. vLLM fetches and imports the attacker's processor module, executing arbitrary Python in the API process. The attacker uses it to steal tokens and weights, open a reverse shell, and pivot into the internal network.

Weaknesses (CWE)

CWE-829Inclusion of Functionality from Untrusted Control SpherePrimary CWE-94Improper Control of Generation of Code ('Code Injection')Primary CWE-94Improper Control of Generation of Code ('Code Injection')Primary CWE-94Improper Control of Generation of Code ('Code Injection')

CWE-829 — Inclusion of Functionality from Untrusted Control Sphere: The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
[Architecture and Design] When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.

Source: MITRE CWE corpus.