vLLM trusted forged shared-memory handles across its multimodal scale-out boundary

The API is supposed to accept multimodal features, not serialized worker memory addresses as bearer authority. In the described chain, the caller stages data in a ring buffer and supplies a forged handle in features.kwargs_data. A worker interprets that pointer-like pair as authorized internal state and deserializes it with Python pickle.

With the multimodal shared-memory cache enabled, an authenticated scale-out API caller can submit a forged address and monotonic_id carrier pointing to attacker-controlled bytes, which a worker passes to pickle.loads. The advisory documents a reproduction on vLLM 0.25.1 and patch 0.32.0. This result requires a particular scale-out and SHM caching configuration plus an authenticated caller. It is not evidence that ordinary text completions permit anonymous remote code execution or that a production service was exploited.

Upgrade to vLLM 0.32.0, disable vulnerable SHM paths while upgrading if feasible, and authenticate every handle with keyed metadata bound to worker state and request lifetime. The path crosses from public request data into a trusted internal cache namespace; disabling a different insecure-serialization flag did not protect that boundary. Primary evidence.

Additional evidence and trust boundary

An address and monotonic_id pair is a pointer to internal state, not evidence that the requesting user owns the cached object. In the reported path, accepting a user-supplied pair leads the worker to deserialize attacker-staged memory with pickle despite a separate insecure-serialization flag. Authenticating the complete handle tuple is the critical boundary; changing a generic serialization setting is not a substitute for validation of the handle origin. Supporting record.