GPU VulnDB

Database/AI/ML frameworks & serving

vLLM (multimodal prompt embeddings, sparse tensor validation): This is the advisory saying the earlier fix did not

NCVD-2026-043-vllm-multimodal-prompt-embeddingAI/ML frameworks & servingGHSA-mcmc-2m55-j8jjcurated

Impact

This is the advisory saying the earlier fix did not hold. The previous remediation for the prompt-embeds denial of service only flipped the feature off by default; the underlying flaw, missing sparse-tensor validation on caller-supplied embeddings, was never addressed. PyTorch disables sparse tensor invariant checks by default for performance, so a malformed tensor with out-of-range or negative indices is accepted and acted on, giving an out-of-bounds write primitive alongside the crash. Any operator who re-enables prompt embeds — which multimodal and embedding-serving deployments routinely do, since that is the feature — is exposed again on a supposedly patched version. Impact runs from killing a shared serving replica to memory corruption in the process holding other tenants' in-flight requests on the GPU node.

Who can reach it

Network, authenticated API client, on any deployment where the prompt-embeds feature is enabled. The attacker submits a crafted sparse tensor as multimodal embedding input in an ordinary request.

What to do

Upgrade to vLLM 0.11.1 or later and restart the servers. Leave prompt embeds disabled unless you genuinely need them; if you need them, do not treat the earlier default-off change as a fix, since it only removed the default exposure. Enforce pod memory limits and restart policy so a corrupted or wedged worker is recycled.

References

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.