GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: caller-controlled EXIF ImageID and cache_salt collide cache keys across requests

CVSS 7.1CVE-2026-114054AI/ML frameworks & servingcurated

Impact

Cache keys in vLLM before 0.31.0 are derived from values the caller supplies - the EXIF ImageID of an uploaded image, and cache_salt for the prefix KV cache. Setting a chosen UUID as EXIF ImageID returns another request's cached processed media, and matching cache_salt to a LoRA name reuses that adapter's first-block KV state. This is a cross-request confidentiality break inside one serving process, which matters most exactly where operators consolidate: a shared inference endpoint serving several tenants or several customer LoRAs on the same GPU leaks one caller's content to another, and no tenant boundary in the orchestration layer helps because the collision happens inside the engine's own cache.

Who can reach it

An authenticated API client of a shared vLLM endpoint that has media or prefix caching enabled. The attacker needs only the ability to set image EXIF fields or the cache_salt request field.

What to do

Upgrade vLLM to 0.31.0 or later and restart the serving processes. If an upgrade has to wait, stop sharing one vLLM process across trust boundaries - give each tenant its own replica - or disable the multimodal media cache and prefix caching, accepting the throughput loss. Strip EXIF from uploaded images and refuse client-supplied cache_salt at the gateway as a partial mitigation.

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.