A model server can confuse a supplied identifier with trusted state

The identifier attached to a model input is not necessarily a trustworthy description of that input. Two vLLM advisories show why this distinction matters when an inference service shares caches or splits multimodal processing across components. Both issues involve the service accepting caller-influenced state without enough binding to what that state is supposed to represent.

The cache-key advisory describes two different sites. In the first, a UUID-valued EXIF ImageID can take precedence over a hash of image bytes, allowing different images to resolve to the same multimodal processor-cache identity. In the second, an untyped first-block prefix-cache key can collide when a caller-controlled cache_salt string equals a LoRA name used as another key component.

These are not the same exploit route. The image path concerns a metadata value claiming to identify content. The prefix path concerns distinct semantic values occupying a key namespace without adequate separation. Both can cause state confusion, but they have different prerequisites and call paths. The vendor lists versions below 0.31.0 as affected and 0.31.0 or later as patched in the relevant advisory.

The scale-out advisory concerns disaggregated multimodal rendering and generation. The affected generation endpoint, POST /inference/v1/generate, accepted serialized encoder tensors and metadata supplied by an authenticated caller as if they were trusted output from the rendering step. The vendor describes engine availability and cache-integrity consequences. It lists versions below 0.30.0 as affected and 0.30.0 as patched.

The attack surfaces should not be merged merely because both concern vLLM and cached or intermediate data. One asks whether a key correctly names its content; the other asks whether internal feature tensors actually came from the trusted rendering component. Neither advisory, as represented in the canonical dossiers, establishes exploitation in the wild, remote shell access or exposure of every installation.

Check the deployed version against the relevant advisory and determine whether the particular cache or disaggregated interface is enabled and reachable under the stated attacker prerequisites. A version number alone cannot demonstrate exploitability without those conditions. At the architecture level, cache keys need both content binding and domain separation; internal feature state needs provenance from the component authorized to create it. The details and patch boundaries are in the cache advisory and scale-out advisory.