CVE-2026-115912
Description
A flaw was found in vLLM. In scale-out deployments utilizing shared-memory multimodal caching, worker nodes fail to validate shared-memory references provided in incoming requests. An authenticated remote attacker can exploit this vulnerability by submitting forged memory references pointing to attacker-controlled data. When the worker process deserializes this untrusted data, it leads to arbitrary code execution.
Statement
This vulnerability is rated as an Important severity for Red Hat AI offerings because an authenticated attacker can achieve arbitrary remote code execution within worker containers. Successful exploitation requires specific non-default configurations, namely running scale-out inference deployments with shared-memory multimodal caching enabled. Standard deployments that do not use multimodal caching across distributed shared memory or where inference APIs are strictly limited to trusted workloads face significantly reduced exposure.
Mitigation
--- CME Mitigation Guidance (2026-11-02) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to cryptographically authenticate shared-memory handles and eliminate the passing of untrusted memory references to pickle.loads() in worker processes: upgrade to vLLM 0.32.0 (or the corresponding fixed Red Hat builds), which sign shared-memory handles with an HMAC derived from a shared secret and reject handles failing signature verification before dereferencing, closing forged shared-memory handle metadata in multimodal kwargs_data. Until patched, this is only a concern on Scale-out Linux deployments with shared-memory multimodal caching enabled — Deployments without shared-memory multimodal caching enabled are unaffected — so Disable shared-memory multimodal caching or strictly restrict authenticated access to inference APIs that submit multimodal request payloads. As a compensating measure, Log anomalous system calls and process executions initiated by the vLLM worker process using auditd, Run SELinux in enforcing mode to confine the worker process domain and limit unauthorized system access, Restrict filesystem paths accessible to the worker process using Landlock sandboxing, Isolate worker processes within dedicated user, PID, network, and mount namespaces, and Drop unnecessary Linux capabilities such as CAP_SYS_ADMIN from worker containers. These controls limit blast radius and contain exploitation, but they do not fix the underlying untrusted deserialization defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-1302 Deserialization Allowlist (Safe Loading) (high)
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.5 | 8.8 | 7.5 |
| Attack Vector | Network | Network | Network |
| Attack Complexity | High | Low | High |
| Privileges Required | Low | Low | Low |
| User Interaction | None | None | None |
| Scope | Unchanged | Unchanged | Unchanged |
| Confidentiality | High | High | High |
| Integrity Impact | High | High | High |
| Availability Impact | High | High | High |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
NVD: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
cve.org: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Understanding the Weakness (CWE)
Integrity
Technical Impact: Modify Application Data; Unexpected State
Attackers can modify unexpected objects or data that was assumed to be safe from modification. Deserialized data or code could be modified without using the provided accessor functions, or unexpected functions could be invoked.
Availability
Technical Impact: DoS: Resource Consumption (CPU)
If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other
Technical Impact: Varies by Context
The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation. One example is attackers using gadget chains to perform unauthorized actions, such as generating a shell.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
