CVE-2026-114053

What it actually does

The flaw forwards an attacker-supplied mm_processor_kwargs.code_revision value directly to Transformers AutoProcessor.from_pretrained, allowing import and execution of arbitrary Python from a chosen revision in the model repository when trust_remote_code is enabled, resulting in RCE inside the vLLM API worker process.

Why it matters to the business

Successful exploitation grants full control over the inference server, enabling data exfiltration, model tampering, lateral movement, or denial of service; the affected software sees broad adoption in production LLM deployments and the issue was published only eight days ago with no patches listed yet.

How an attack unfolds

An attacker who can publish a malicious revision to the model repository sends a crafted multimodal request containing a code_revision value to the unauthenticated /tokenize endpoint; because the parameter is passed through without validation, the chosen revision's processor code is imported and executed with the privileges of the vLLM API process.

How to fix it

Upgrade vLLM from any version in the 0.7.3–0.30.x range to 0.31.0 or newer; if an immediate upgrade is impossible, disable trust_remote_code globally or place authentication and network restrictions in front of the /tokenize endpoint.

How to confirm the fix worked

Confirm the running vLLM binary or container reports version 0.31.0 or later; attempt a request containing mm_processor_kwargs.code_revision and verify the parameter is rejected or ignored; review startup logs for the string trust_remote_code.

Typical attack path

1. Locate a reachable vLLM instance exposing the /tokenize endpoint with trust_remote_code enabled
2. Upload or modify a model revision containing malicious Python code in the served repository
3. Issue a POST request to /tokenize that includes mm_processor_kwargs.code_revision pointing to the malicious revision
4. Achieve arbitrary Python execution inside the vLLM worker

How to detect it

Search web-server and application logs for POST requests to /tokenize that contain the substring mm_processor_kwargs or code_revision; correlate with process-creation or import events inside the vLLM worker; inspect model-repository commit history for unexpected revisions added around the time of suspicious requests.

• POST /tokenize.*mm_processor_kwargs
• code_revision
• trust_remote_code=True
• AutoProcessor.from_pretrained.*revision

What your security team should do

• Upgrade to vLLM 0.31.0 immediately given the RCE impact and unauthenticated exposure
• Disable trust_remote_code unless explicitly required for the workload
• Require authentication on all inference endpoints including /tokenize
• Add network ACLs or WAF rules to restrict direct access to the tokenize endpoint
• Monitor EPSS and KEV status for changes and reassess within the next 30 days