CVE-2026-86793 in SGLang
Summary
by MITRE • 09/11/2026
SGLang allows unauthenticated pickle deserialization through /update_weights_from_tensor when no auth keys are configured, and the SafeUnpickler policy can be bypassed because builtins.import and builtins.getattr are resolvable, enabling code execution via pickle REDUCE.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability in SGLang represents a critical insecure deserialization flaw located within the /update_weights_from_tensor endpoint. This specific interface is designed to allow for the dynamic updating of model weights during runtime operations, which inherently requires handling serialized data structures. However, when authentication keys are not configured or left empty, the system fails to enforce any access control mechanisms before processing incoming requests. This lack of mandatory authentication creates an unauthenticated attack vector that allows remote attackers to interact directly with the deserialization logic without providing valid credentials. The core technical issue stems from the use of Python's pickle module for data serialization and deserialization. Pickle is known to be inherently unsafe because it can instantiate arbitrary objects during the unpickling process, provided those classes are available in the current namespace.
The specific mechanism exploited involves bypassing the SafeUnpickler policy that SGLang attempts to implement as a mitigation measure. While many applications attempt to secure pickle deserialization by restricting allowed modules and functions within their custom Unpickler subclasses, this implementation contains a critical logic error. The SafeUnpickler restricts certain dangerous built-in functions but fails to adequately sandbox the resolution of attributes on standard library objects. Specifically, an attacker can leverage the resolvable nature of builtins.import and builtins.getattr. By constructing a carefully crafted pickle payload that utilizes these accessible methods within the REDUCE opcode sequence, it is possible to import arbitrary modules or access specific class attributes without triggering the security restrictions intended by the SafeUnpickler. This bypass effectively neutralizes the protective layer designed to prevent code execution during deserialization.
The operational impact of this vulnerability is severe, resulting in Remote Code Execution on any server instance where SGLang is deployed with unconfigured authentication. An attacker can craft a malicious pickle payload that executes arbitrary system commands or performs other destructive actions upon successful deserialization by the vulnerable endpoint. This compromise grants full control over the underlying operating system processes running the SGLang service, potentially leading to data exfiltration, lateral movement within the network, and complete loss of integrity for the machine learning models being served. The ability to execute code remotely without authentication significantly lowers the barrier for exploitation, making this vulnerability highly attractive to automated scanning tools and opportunistic attackers targeting exposed inference endpoints.
From a classification perspective, this issue aligns with CWE-502 Deserialization of Untrusted Data, as it involves processing data from an untrusted source in a way that allows unintended code execution. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques related to Command and Scripting Interpreter abuse via deserialization artifacts. The specific use of pickle REDUCE opcodes with built-in function resolution is characteristic of advanced persistent threats looking for reliable persistence mechanisms or initial access vectors in Python-based environments.
To mitigate this vulnerability, it is imperative that authentication be strictly enforced on all API endpoints within SGLang, particularly those handling serialized data like /update_weights_from_tensor. Administrators must ensure that valid auth keys are configured and validated before any deserialization logic is triggered. Additionally, the SafeUnpickler implementation should be reviewed to explicitly block or restrict access to builtins.import and builtins.getattr if they are not strictly required for legitimate functionality. In cases where pickle is necessary, consider migrating to safer serialization formats such as JSON or MessagePack that do not support arbitrary object instantiation. If pickle must remain in use, implementing a strict allowlist of permitted classes and functions within the unpickler context, rather than relying on broad exclusions, will provide more robust protection against similar bypass techniques.