CVE-2026-115912 in vLLM
Summary
by MITRE • 10/26/2026
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, an authenticated caller can place forged shared-memory address and monotonic_id values in public multimodal features.kwargs_data. In scale-out deployments with shared-memory multimodal caching enabled, workers trust those values and pass attacker-selected bytes to pickle.loads(), allowing arbitrary Python execution even when insecure serialization is disabled. This issue is fixed in version 0.32.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in vLLM versions prior to 0.32.0 represents a critical security flaw within the inference and serving engine for large language models, specifically affecting deployments that utilize shared-memory multimodal caching in scale-out architectures. This issue stems from an insufficient validation of input data passed through public multimodal features kwargs_data. Specifically, authenticated users are able to inject forged values for shared-memory addresses and monotonic identifiers into this data structure. In a distributed environment where multiple worker processes rely on shared memory for performance optimization, these workers blindly trust the integrity of the provided address pointers and sequence IDs without performing adequate verification against expected bounds or state consistency checks.
The core technical flaw lies in how the system handles serialized objects derived from this untrusted input. When an attacker supplies maliciously crafted shared-memory addresses and monotonic identifiers, the vLLM worker processes interpret these values as valid references to cached multimodal data. Consequently, the engine proceeds to deserialize the content associated with these forged pointers using Python's pickle module via the loads function. This behavior persists even when insecure serialization is ostensibly disabled in the configuration settings, indicating that the security control was bypassed through the manipulation of memory addressing logic rather than a direct override of the deserialization flag. The ability to pass attacker-selected bytes directly into pickle.loads constitutes an arbitrary code execution vulnerability, as Python's pickle module can instantiate objects and execute methods during the unpickling process if those classes contain dangerous dunder methods such as _reduce_ or custom initialization routines that trigger system commands.
From a threat modeling perspective, this vulnerability aligns with CWE-502, which describes deserialization of untrusted data, but is exacerbated by CWE-1346 due to the specific mechanism involving shared memory manipulation and pointer forgery. The attack vector allows for remote code execution on any worker node participating in the scale-out deployment that has multimodal caching enabled. An authenticated attacker can leverage this flaw not only to execute arbitrary Python code within the context of the vLLM process but also potentially to escalate privileges if the service runs with elevated permissions or access sensitive internal resources. The impact is severe, as it compromises the confidentiality, integrity, and availability of the model serving infrastructure by allowing full control over the underlying operating system processes running the inference engine.
This incident maps directly to MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter sub-techniques such as Python (T1059.006), where attackers use scripting languages like Python to execute commands on a target system. Furthermore, it relates to T1203, Exploitation for Client Execution or Service Execution, depending on whether the attack targets user-facing endpoints or background worker services. The exploitation relies heavily on the trust relationship between different components in a distributed architecture, highlighting the risks associated with shared-memory optimizations when input validation is lax.
To mitigate this vulnerability, organizations must immediately upgrade vLLM to version 0.32.0 or later, where the developers have implemented stricter validation for shared-memory addresses and monotonic IDs before they are processed by the deserialization logic. In environments where upgrading is not immediately feasible, it is advisable to disable multimodal caching in scale-out deployments if possible, thereby removing the attack surface related to shared memory pointer manipulation. Additionally, implementing strict network segmentation to limit access to vLLM endpoints only to trusted authenticated users can reduce the risk of exploitation by external actors. Security teams should also audit their configurations to ensure that no legacy or custom code paths bypass standard deserialization safeguards, and consider deploying runtime application self-protection tools that monitor for suspicious pickle usage patterns in production environments.