Summary
A code injection vulnerability in vLLM allows a client-supplied processor revision to influence which dynamic multimodal processor code Transformers imports.
When remote code trust is enabled and an attacker controls the selected model revision, an unauthenticated request to the tokenization endpoint may execute arbitrary Python in the vLLM API process.
A code injection vulnerability in vLLM allows a client-supplied processor revision to influence which dynamic multimodal processor code Transformers imports.
When remote code trust is enabled and an attacker controls the selected model revision, an unauthenticated request to the tokenization endpoint may execute arbitrary Python in the vLLM API process.
Affected context
The vulnerability can occur in vLLM deployments that:
- Serve multimodal models through the affected processor-loading path
- Enable Transformers dynamic processor code through
trust_remote_code - Forward request-controlled
mm_processor_kwargs.code_revisionvalues - Expose the
/tokenizeendpoint to clients without sufficient authentication or authorization
Exploitation also depends on an attacker being able to control or influence code associated with the selected model revision.
The vulnerability can occur in vLLM deployments that:
- Serve multimodal models through the affected processor-loading path
- Enable Transformers dynamic processor code through
trust_remote_code - Forward request-controlled
mm_processor_kwargs.code_revisionvalues - Expose the
/tokenizeendpoint to clients without sufficient authentication or authorization
Exploitation also depends on an attacker being able to control or influence code associated with the selected model revision.
Exploit preconditions
- Attack surface: The vLLM
/tokenizeAPI endpoint handling multimodal requests - Required access: The ability to send requests to the endpoint; authentication may not be required in exposed deployments
- Trigger point: Processor resolution through
Transformers AutoProcessor.from_pretrained - Additional condition:
trust_remote_codemust permit dynamic processor code - Why exploitation is possible: A request-supplied revision is forwarded into dynamic code-loading logic, allowing a client-controlled model revision to determine imported Python code
- Attack surface: The vLLM
/tokenizeAPI endpoint handling multimodal requests - Required access: The ability to send requests to the endpoint; authentication may not be required in exposed deployments
- Trigger point: Processor resolution through
Transformers AutoProcessor.from_pretrained - Additional condition:
trust_remote_codemust permit dynamic processor code - Why exploitation is possible: A request-supplied revision is forwarded into dynamic code-loading logic, allowing a client-controlled model revision to determine imported Python code
Why this happens
The underlying issue is insufficient separation between request data and trusted code-selection parameters.
vLLM forwards the client-controlled mm_processor_kwargs.code_revision value to a dynamic processor loader. When remote code execution is trusted, the loader can import Python implementation code associated with the selected model revision. Treating a request-controlled revision as trusted executable-code metadata creates a code injection condition, mapping to CWE-94: Improper Control of Generation of Code ('Code Injection').
The underlying issue is insufficient separation between request data and trusted code-selection parameters.
vLLM forwards the client-controlled mm_processor_kwargs.code_revision value to a dynamic processor loader. When remote code execution is trusted, the loader can import Python implementation code associated with the selected model revision. Treating a request-controlled revision as trusted executable-code metadata creates a code injection condition, mapping to CWE-94: Improper Control of Generation of Code ('Code Injection').
Potential impact
- An attacker could execute arbitrary Python in the vLLM API process
- The attacker could access process data, credentials, or mounted resources available to the service
- The model-serving workload could be modified or disrupted
- Compromised credentials could enable lateral movement into connected services
- The incident could contribute to model, data, or supply-chain tampering
- An attacker could execute arbitrary Python in the vLLM API process
- The attacker could access process data, credentials, or mounted resources available to the service
- The model-serving workload could be modified or disrupted
- Compromised credentials could enable lateral movement into connected services
- The incident could contribute to model, data, or supply-chain tampering
General mitigation guidance
Mitigation generally focuses on removing client control over executable-code revisions and reducing trust in dynamically loaded model code.
Common defensive patterns include:
- Disable dynamic remote processor code unless it is explicitly required
- Use a strict allowlist of trusted models, repositories, revisions, and processor implementations
- Ignore or reject client-supplied code-selection parameters at the API boundary
- Separate model metadata from executable code-selection inputs
- Require authentication and authorization for multimodal processing endpoints
- Run model-serving processes with least privilege and minimal filesystem, network, and credential access
- Isolate model workloads so compromise of one API process does not expose broader infrastructure
Mitigation generally focuses on removing client control over executable-code revisions and reducing trust in dynamically loaded model code.
Common defensive patterns include:
- Disable dynamic remote processor code unless it is explicitly required
- Use a strict allowlist of trusted models, repositories, revisions, and processor implementations
- Ignore or reject client-supplied code-selection parameters at the API boundary
- Separate model metadata from executable code-selection inputs
- Require authentication and authorization for multimodal processing endpoints
- Run model-serving processes with least privilege and minimal filesystem, network, and credential access
- Isolate model workloads so compromise of one API process does not expose broader infrastructure
How teams detect issues like this
Detection approaches can include:
- Static analysis for request-derived values reaching dynamic import or remote-code-loading APIs
- Code review checks for
code_revisionor similar parameters flowing into processor and model loaders - Runtime logging of model repository, revision, and remote-code loading decisions
- API policy checks that reject unexpected processor-selection parameters
- Network and identity monitoring for unauthenticated access to tokenization or multimodal endpoints
- Automated security review tools that flag trust-boundary violations involving dynamic code loading
Detection approaches can include:
- Static analysis for request-derived values reaching dynamic import or remote-code-loading APIs
- Code review checks for
code_revisionor similar parameters flowing into processor and model loaders - Runtime logging of model repository, revision, and remote-code loading decisions
- API policy checks that reject unexpected processor-selection parameters
- Network and identity monitoring for unauthenticated access to tokenization or multimodal endpoints
- Automated security review tools that flag trust-boundary violations involving dynamic code loading
