vLLM: malformed multimodal embedding input crashes the engine and drops every in-flight request

CVSS 8.3CVE-2025-62372AI/ML frameworks & servingcurated

Impact

Any client allowed to call the API of a vLLM server running a multimodal model can kill the engine by sending an embedding tensor with the right number of dimensions but the wrong hidden size. The engine process dies, taking all co-resident requests with it, and the model has to be reloaded into GPU memory - tens of seconds to minutes of dead accelerator time per crash on large weights. On a shared endpoint this is a single-request denial of service against every other tenant on that replica, repeatable at will. It applies whether or not the served model is documented as accepting embedding inputs.

Who can reach it

Network reachable to the vLLM HTTP API; the CVSS vector records low-privilege authentication (PR:L), so any tenant or application holding a valid API key qualifies. No access to the host or the GPU is needed.

What to do

Upgrade to vLLM 0.11.1 or later and restart each serving process - a rolling restart across replicas keeps the endpoint up, but every replica reloads its weights. If the upgrade cannot be scheduled, reject or strip multimodal embedding inputs at the gateway in front of vLLM and keep the API off untrusted networks.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-62372 https://github.com/vllm-project/vllm/security/advisories/GHSA-pmqf-x6x8-p7qw https://github.com/vllm-project/vllm/commit/58fab50d82838d5014f4a14d991fdb9352c9c84b

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.