CVE-2026-115912

vLLM: Public multimodal SHM handle forgery reaches worker-side pickle.loads() with insecure serialization disabled

# vllm/entrypoints/scale_out/token_in_token_out/serving.py Lines 155-165
            # Deserialize tensor data when present; None → cache hit.
            mm_kwargs: dict[str, list[MultiModalKwargsItem | None]] = {}
            if features.kwargs_data is not None:
                for modality, items in features.kwargs_data.items():
                    mm_kwargs[modality] = [
                        decode_mm_kwargs_item(item) if item is not None else None
                        for item in items
                    ]
            else:
                for modality, hashes in features.mm_hashes.items():
                    mm_kwargs[modality] = [None] * len(hashes)

# vllm/multimodal/cache.py Lines 711-723
    @override
    def get_and_update_item(
        self,
        mm_item: MultiModalKwargsItem | None,
        mm_hash: str,
    ) -> MultiModalKwargsItem:
        assert mm_item is not None, f"Expected an address item for {mm_hash=}"
        if "address" in mm_item:
            address = cast(int, mm_item["address"].data)
            monotonic_id = cast(int, mm_item["monotonic_id"].data)
            return self._shm_cache.get(address, monotonic_id)

        return mm_item

# vllm/distributed/device_communicators/shm_object_storage.py Lines 375-400
    def deserialize(self, data_view: 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
        type_name, nbytes, len_arr = pickle.loads(data_view)
        serialized_data = data_view[-nbytes:]

        if type_name == torch.Tensor.__name__:
            obj = []
            start_idx = 0
            for length in len_arr:
                item_bytes = serialized_data[start_idx : start_idx + length]
                obj.append(item_bytes)
                start_idx += length
            obj = self.tensor_decoder.decode(obj)
        elif type_name == self._mm_kwargs_item_cls.__name__:
            obj = []
            start_idx = 0
            for length in len_arr:
                item_bytes = serialized_data[start_idx : start_idx + length]
                obj.append(item_bytes)
                start_idx += length
            obj = self.mm_decoder.decode(obj)
        elif type_name == bytes.__name__:
            obj = pickle.loads(serialized_data)
        else:
            raise ValueError(f"Unsupported object type '{type_name}' in metadata")

        return obj

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 VLLM_ALLOW_INSECURE_SERIALIZATION=0; it abuses the built-in SHM object deserializer, not the separate optional msgpack ext-hook flag.

Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect. Typical impact: arbitrary code execution or logic abuse.

CVE-2026-115912 has a CVSS score of 7.5 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.32.0); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

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 (cache_key, address, monotonic_id) alongside the pair. The public scale-out path validates it before engine handoff:

# vllm/entrypoints/scale_out/token_in_token_out/serving.py
        cache = self.online_renderer.renderer.mm_processor_cache
        for mm_hash, item in zip(hashes, items):
            decoded_item = decode_mm_kwargs_item(item) if item is not None else None
            if decoded_item is not None and cache is not None:
                # Rejects a forged (address, monotonic_id) that lacks a valid
                # server-issued capability for this cache key.
                cache.validate_input_item(decoded_item, mm_hash)
            decoded_items.append(decoded_item)

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

# vllm/distributed/device_communicators/shm_object_storage.py
    def get(self, address, monotonic_id, capability=None, key=None):
        if not self.is_writer:
            # Reject forged handles before dereferencing the supplied address.
            self.validate_capability(key, address, monotonic_id, capability)
        with self.ring_buffer.access_buf(address) as (data_view, buf_metadata):
            self._validate_monotonic_id(address, monotonic_id, buf_metadata)
            obj = self.ser_de.deserialize(data_view[self.flag_bytes :])
            ...

where validate_capability recomputes the HMAC with hmac.compare_digest 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.

1. What is CVE-2026-115912? CVE-2026-115912 is a high-severity insecure deserialization vulnerability in vllm (pip), affecting versions < 0.32.0. It is fixed in 0.32.0. Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect.
2. How severe is CVE-2026-115912? CVE-2026-115912 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of vllm are affected by CVE-2026-115912? vllm (pip) versions < 0.32.0 is affected.
4. Is there a fix for CVE-2026-115912? Yes. CVE-2026-115912 is fixed in 0.32.0. Upgrade to this version or later.
5. Is CVE-2026-115912 exploitable, and should I be worried? Whether CVE-2026-115912 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-115912 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-115912? Upgrade vllm to 0.32.0 or later.

Other vulnerabilities in vllm