Database/AI/ML frameworks & serving
vLLM (multimodal prompt embeddings, sparse tensor validation): This is the advisory saying the earlier fix did not
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.