High priorityDisclosed

Advisory · CVE-2026-114053

vLLM tokenize endpoint can run attacker-chosen model processor code when remote code is trusted

vLLM from 0.7.3 before 0.31.0 forwards a request-supplied code_revision to Transformers AutoProcessor loading, so a client can select which revision of a model processor is imported when trust_remote_code is enabled, executing arbitrary Python in the vLLM API process. CVSS 3.1 8.1 (CVSS 4.0 9.2).

Advisory published October 21, 2026Independent summary
Vendor
vLLM
Product
vLLM
Identifier / CWE
CVE-2026-114053
CWE-94
Action timing
Immediate
ELI5

Explain it like I’m five

vLLM lets a request name which edition of a model helper script to load, and when remote code is trusted it loads that edition without checking it is the one the operator pinned.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01Attacker revision prepared

    An attacker controls a revision in the served model repository whose dynamic processor code they can choose.

  2. 02Crafted tokenize request sent

    The attacker sends a multimodal request to the unauthenticated /tokenize endpoint with mm_processor_kwargs naming that code_revision.

  3. 03Revision forwarded unchecked

    vLLM forwards the request-supplied code_revision to Transformers AutoProcessor.from_pretrained.

  4. 04Attacker code imported

    When trust_remote_code is enabled, the processor code from the attacker-chosen revision is imported.

  5. 05Code runs in the API process

    Arbitrary Python executes in the vLLM API process, with that process permissions and network reach.

What happened

The vLLM project disclosed CVE-2026-114053: 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 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. The CVSS 3.1 score is 8.1 and the CVSS 4.0 score is 9.2; exploitation depends on the trust_remote_code condition and attacker control of a model revision, both stated in the record.

Per the affected data in the NVD record, versions from 0.7.3 before 0.31.0 are affected and 0.31.0 is listed as unaffected, so upgrading to vLLM 0.31.0 or later is the stated fix.

What to do

  1. Inventory vLLM serving instances, including internal, research, and hosted inference endpoints, and note the version and whether trust_remote_code is enabled for each.
  2. Upgrade affected instances to vLLM 0.31.0 or later using the project release guidance.
  3. Disable trust_remote_code wherever the served model does not strictly require it, and pin model revisions in server configuration rather than accepting them per request.
  4. Restrict access to the /tokenize endpoint and other unauthenticated serving endpoints to intended clients while remediation is underway.
  5. Hunt for tokenize requests carrying mm_processor_kwargs or code_revision values, unexpected processor downloads, and child processes spawned by the vLLM API process.
  6. Verify the deployed version after updating and confirm client-supplied revisions are no longer honored.

Management note

LLM serving hosts usually hold model weights, API keys, and cloud credentials in one process. A request-level path to arbitrary Python in that process is a platform compromise, not a model bug, so patch it and turn off trusted remote code wherever you can.