vLLM EUVD-2026-107005

Requires valid authenticated access to the vLLM API (PR:L) AND a deployment that shares caches across multiple distinct callers/tenants. The attacker must control request-supplied values that feed cache keys - specifically an EXIF ImageID (set to a UUID matching a target) for the multimodal/image-processing cache, or cache_salt (matched to a LoRA name) for prefix/first-block KV cache reuse - which means the relevant caching paths (image/multimedia processing cache and/or prefix KV caching) must be in use. Limiting factors that reduce real-world risk: exploitation is impossible without authentication, requires a multi-user/shared-cache configuration (single-tenant deployments have nothing to collide against), and requires the attacker to supply or guess colliding key values; all affected deployments must be running vLLM before 0.31.0.

The vendor-supplied CVSS 4.0 base score is 7.1 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N, indicating a network-reachable, low-complexity attack requiring only low-level authenticated access and no user interaction - a genuinely accessible flaw for anyone with API credentials on a shared vLLM instance. However, the impact metrics in the supplied vector are internally inconsistent with the description: the vector asserts VA:H (high availability impact) with VC:N/VI:N (no confidentiality or integrity impact), yet the description describes an attacker receiving another request's cached processed media and reusing another request's KV state - which is fundamentally a cross-tenant confidentiality/integrity problem, not an availability problem. This discrepancy should be verified with the vendor advisory (GHSA-rh6f-3x46-j33q); my independent assessment treats the primary impact as confidentiality. No EPSS score, SSVC decision, KEV listing, or public POC was provided in the input, so exploitation likelihood cannot be quantified and there is no public exploit identified at time of analysis. Net judgment: this is a real priority specifically for multi-tenant/multi-user vLLM deployments (shared caches across distinct callers), where cross-request data leakage is the direct consequence; single-tenant or single-user deployments face substantially lower real-world risk because there are no other requests' caches to collide with.

On a shared multi-tenant vLLM endpoint (before 0.31.0), an authenticated attacker submits a request whose image carries an EXIF ImageID set to a UUID that collides with a victim's cache key, or sets cache_salt to match a LoRA name, causing the server to return another request's cached processed media or reuse its first-block KV state. This leaks the victim's content or taints the attacker's own inference with another user's cached state. No public exploit code was identified in the provided data; exploitation is network-reachable and low-complexity but requires valid API authentication.