GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: forged shared-memory handles in multimodal kwargs reach pickle.loads on workers

CVSS 8.8CVE-2026-115912AI/ML frameworks & servingcurated

Impact

An authenticated caller of the vLLM API can put attacker-chosen shared-memory addresses and monotonic_id values into the public features.kwargs_data field of a multimodal request. In scale-out deployments with shared-memory multimodal caching enabled, worker processes trust those values and hand the referenced bytes to pickle.loads(), which gives arbitrary Python execution inside the worker - the process that holds the GPU context and the loaded model weights. This bypasses the protection operators expect from disabling insecure serialization, so a deployment that was explicitly hardened is still exploitable. On a GPU fleet that means any tenant or app with API credentials can run code on the serving node, read other requests in flight, and tamper with model weights in memory; the node must be restarted and treated as compromised.

Who can reach it

Network access to the vLLM API with valid credentials (PR:L). Only affects scale-out deployments that have shared-memory multimodal caching enabled.

What to do

Upgrade to vLLM 0.32.0 and restart the API server and all worker processes; a rolling restart per replica is enough, no node reboot or firmware work. Until then, disable shared-memory multimodal caching and restrict who can call the endpoint.

References

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.