GHSA-6757-hggm-hp2w: High severity pip/vllm vulnerability

Affected

- Ecosystem / package: pip / vllm - Affected versions: vLLM < 0.32.0.

Summary

When --mm-processor-cache-type shm is enabled, vLLM's multimodal SHM cache represents a cached item with an address and monotonicid pair and treats that pair as authority to dereference shared memory in the worker. A public scale-out request can supply its own multimodal features.kwargsdata, so an authenticated caller can forge an inner SHM carrier that points at attacker-controlled bytes already staged in the ring buffer. The worker then reaches pickle.loads() while deserializing the forged object.

This is reachable through ordinary public HTTP routes and does not require VLLMALLOWINSECURESERIALIZATION=1. The live chain used /v1/chat/completions/render to obtain a valid feature envelope, /v1/chat/completions to stage attacker-chosen bytes into SHM, and /inference/v1/generate to submit the forged inner carrier.

Affected code

Links pinned to the confirmed commit 752a3a504485 (v0.25.1):

- vllm/distributed/devicecommunicators/shmobjectstorage.py#L375-L400 — SHM object deserialization reaches pickle.loads(serializeddata) for byte objects. - vllm/multimodal/cache.py#L567-L581 — sender emits an SHM carrier containing only address and monotonicid. - vllm/multimodal/cache.py#L711-L737 — worker dereferences the untrusted pair and reads the SHM object. - vllm/entrypoints/scaleout/tokenintokenout/serving.py#L146-L173 — public features.kwargsdata is decoded into engine input without authenticating SHM handles before handoff.

The public scale-out route decodes attacker-controlled features.kwargsdata into MultiModalKwargsItems and hands them straight to the engine — no authentication of the SHM handle:

python vllm/entrypoints/scaleout/tokenintokenout/serving.py Lines 155-165 # Deserialize tensor data when present; None → cache hit. mmkwargs: dict[str, list[MultiModalKwargsItem | None]] = {} if features.kwargsdata is not None: for modality, items in features.kwargsdata.items(): mmkwargs[modality] = [ decodemmkwargsitem(item) if item is not None else None for item in items ] else: for modality, hashes in features.mmhashes.items(): mmkwargs[modality] = [None] len(hashes)

In the worker, a decoded item that carries an address is treated as authority to dereference shared memory: the (address, monotonicid) pair alone drives the read, with no binding to the cache key or to who issued the handle:

python vllm/multimodal/cache.py Lines 711-723 @override def getandupdateitem( self, mmitem: MultiModalKwargsItem | None, mmhash: str, ) -> MultiModalKwargsItem: assert mmitem is not None, f"Expected an address item for {mmhash=}" if "address" in mmitem: address = cast(int, mmitem["address"].data) monotonicid = cast(int, mmitem["monotonicid"].data) return self.shmcache.get(address, monotonicid)

return mmitem

The dereference lands in the SHM deserializer, which pickle.loads() any chunk tagged as bytes — so attacker bytes staged in the ring buffer are unpickled in the worker process:

python vllm/distributed/devicecommunicators/shmobjectstorage.py Lines 375-400 def deserialize(self, dataview: memoryview) -> Any: # pickle.loads do not read past the end of a pickled object # within a large buffer, so we can skip storing the metadata size typename, nbytes, lenarr = pickle.loads(dataview) serializeddata = dataview[-nbytes:]

if typename == torch.Tensor.name: obj = [] startidx = 0 for length in lenarr: itembytes = serializeddata[startidx : startidx + length] obj.append(itembytes) startidx += length obj = self.tensordecoder.decode(obj) elif typename == self.mmkwargsitemcls.name: obj = [] startidx = 0 for length in lenarr: itembytes = serializeddata[startidx : startidx + length] obj.append(itembytes) startidx += length obj = self.mmdecoder.decode(obj) elif typename == bytes.name: obj = pickle.loads(serializeddata) else: raise ValueError(f"Unsupported object type '{typename}' in metadata")

return obj

Impact

An ordinary authenticated inference caller can execute arbitrary Python in the worker process on a deployment that uses SHM multimodal caching. The live proof used a benign marker gadget and also caused the EngineCore health endpoint to fall from 200 to 503 after the forged request. The exploit is reachable with VLLMALLOWINSECURESERIALIZATION=0; it abuses the built-in SHM object deserializer, not the separate optional msgpack ext-hook flag.

Suggested Fix

Authenticate every SHM carrier with a server-issued capability bound to the cache key, address, and monotonic id; rotate the capability secret when the cache is cleared; and reject malformed or forged SHM carriers at the public scale-out boundary before engine handoff — so a forged pair never reaches the worker deref / pickle.loads().

The sender emits an HMAC capability (keyed by a 32-byte secret stored in the ring buffer and rotated on clear()) over (cachekey, address, monotonicid) alongside the pair. The public scale-out path validates it before engine handoff:

python vllm/entrypoints/scaleout/tokenintokenout/serving.py cache = self.onlinerenderer.renderer.mmprocessorcache for mmhash, item in zip(hashes, items): decodeditem = decodemmkwargsitem(item) if item is not None else None if decodeditem is not None and cache is not None: # Rejects a forged (address, monotonicid) that lacks a valid # server-issued capability for this cache key. cache.validateinputitem(decodeditem, mmhash) decodeditems.append(decodeditem)

The worker get() re-checks the capability on the reader side before it ever dereferences the caller-supplied address:

python vllm/distributed/devicecommunicators/shmobjectstorage.py def get(self, address, monotonicid, capability=None, key=None): if not self.iswriter: # Reject forged handles before dereferencing the supplied address. self.validatecapability(key, address, monotonicid, capability) with self.ringbuffer.accessbuf(address) as (dataview, bufmetadata): self.validatemonotonicid(address, monotonicid, bufmetadata) obj = self.serde.deserialize(dataview[self.flagbytes :]) ...

where validatecapability recomputes the HMAC with hmac.comparedigest and raises Missing server-issued SHM capability for cache key. / Invalid server-issued SHM capability for cache key. on any mismatch. The fix applies cleanly to v0.25.1 and ships regression tests asserting the generate path rejects an invalid handle and that the receiver requires a matching sender handle (and a capability issued after the current clear()) for the cache key.

Credit

Reported by: Patch the Planet (Trail of Bits + OpenAI collaboration)

This vulnerability was discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.

---

Proposed fix: a proposed change for this issue is up for review in this advisory's temporary private fork: https://github.com/vllm-project/vllm-ghsa-6757-hggm-hp2w/pull/1

This advisory was fixed in MR59357.