CVE-2026-93034 in SGLang
Summary
by MITRE • 10/08/2026
SGLang contains an arbitrary code execution vulnerability caused by the ZMQ message decoder unconditionally deserializing PickleWrapper payloads via pickle.loads() in _maybe_unwrap_pickle without type allowlisting or authentication; this vulnerability persists via the msgpack path even when SGLANG_USE_PICKLE_IPC is disabled, and becomes remotely exploitable if data-parallel attention is enabled with a non-loopback --dist-init-addr setting.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The security flaw identified in SGLang represents a critical arbitrary code execution vulnerability rooted in the improper handling of serialized objects within its inter-process communication layer. Specifically, the ZMQ message decoder contains a function named _maybe_unwrap_pickle that unconditionally invokes Python's pickle.loads() method on incoming PickleWrapper payloads. This implementation fails to implement any form of type allowlisting or authentication mechanism before deserialization occurs. In standard software security practices, relying on unpickling data from untrusted sources is considered dangerous because the pickle module can instantiate arbitrary objects and execute code during the reconstruction process. The absence of validation allows an attacker to craft malicious serialized payloads that, when processed by this function, result in the execution of arbitrary commands with the privileges of the running SGLang instance.
A particularly concerning aspect of this vulnerability is its persistence across different configuration states. Although there exists a configuration flag named SGLANG_USE_PICKLE_IPC intended to control whether pickle-based inter-process communication is utilized, the flaw persists even when this flag is disabled. This indicates that the underlying msgpack path or related deserialization logic still processes these payloads in a manner that triggers the vulnerable code path. Consequently, disabling the explicit pickle IPC setting does not mitigate the risk, as the system continues to deserialize untrusted data through mechanisms that inadvertently invoke unsafe serialization routines. This design oversight means that administrators cannot rely on configuration toggles alone to secure the application against this specific attack vector.
The operational impact of this vulnerability is severe, particularly in distributed computing environments where SGLang is deployed for large language model inference or training tasks. The vulnerability becomes remotely exploitable under specific network configurations. If data-parallel attention is enabled and the distribution initialization address (--dist-init-addr) is set to a non-loopback interface, the service exposes itself to external networks rather than restricting communication to localhost only. In such scenarios, an attacker on the same network can send crafted ZMQ messages containing malicious pickle payloads directly to the vulnerable endpoint. Successful exploitation allows for complete system compromise, enabling the execution of arbitrary code, data exfiltration, or further lateral movement within the internal network infrastructure.
To mitigate this risk, immediate remediation efforts should focus on restricting network exposure and updating software components if patches are available. Administrators must ensure that SGLang instances using data-parallel attention do not bind to non-loopback interfaces unless absolutely necessary for legitimate distributed operations. If remote access is required, it should be protected by robust authentication mechanisms such as TLS mutual authentication or ZMQ security layers like CURVE encryption and identity verification, which can prevent unauthorized parties from sending messages to the service. Furthermore, developers must refactor the _maybe_unwrap_pickle function to implement strict type allowlisting before deserialization occurs. This involves validating that incoming payloads belong to expected, safe data types rather than blindly passing them to pickle.loads(). Adhering to CWE-502 guidelines for Deserialization of Untrusted Data and aligning with ATT&CK technique T1610 (Exploitation for Remote Code Execution) is essential for hardening the application against similar future threats.