vLLM: remote processor code executes even when trust_remote_code is false

CVSS 8.5CVE-2026-90553AI/ML frameworks & servingcurated

Impact

A model whose repository contains processing_llava_onevision2.py gets that Python executed inside the vLLM process, because the LlavaOnevision2 processor loader never consults trust_remote_code. Operators who rely on trust_remote_code=False as the boundary that lets them serve tenant- or hub-supplied weights lose it entirely: loading a model is enough to run code with the serving process's authority. On a GPU node that means whatever the inference service can reach - the GPU devices, the model cache, the service account token mounted into the pod, any shared weight store. Anywhere users pick their own model id, this is a model-supplied RCE, not a configuration mistake.

Who can reach it

Anyone who can influence which model vLLM loads - a tenant choosing a model id, a hub mirror, or a shared weights bucket. No authentication against vLLM itself is needed if model selection is user-facing; the CVSS vector rates it local with user interaction, matching the case where an operator loads the attacker's model.

What to do

Upgrade to vLLM 0.28.0 and restart each serving process; a rolling restart across replicas is enough, no node reboot. Until then, pin model loads to an allow-list of reviewed model ids and do not let tenants point vLLM at arbitrary repositories - trust_remote_code=False does not protect this path.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-90553 https://github.com/vllm-project/vllm/security/advisories/GHSA-3c86-2m5g-59q7 https://www.vulncheck.com/advisories/vllm-before-0.28.0-remote-code-execution-via-llavaonevision2-processor

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.