CVE-2026-7301: SGLang Scheduler RCE via Pickle Deserialization

Executive Summary

A critical remote code execution vulnerability identified as CVE-2026-7301 (CVSS 9.8) affects the SGLang multimodal generation runtime. The flaw resides in the scheduler's ROUTER socket, which binds to 0.0.0.0 by default and processes incoming messages through a sink that calls Python's pickle.loads() without sanitization. An unauthenticated attacker who can reach the exposed socket can send a crafted pickle payload to achieve arbitrary code execution on the host. The vulnerability was disclosed by the anti-proof research team in a blog post detailing three RCE flaws in SGLang. No evidence of active exploitation has been reported as of publication, but the default network exposure makes this a high-priority patch target for any organization running SGLang on internet-facing infrastructure.

Technical Analysis

CVE-2026-7301 is a classic insecure deserialization vulnerability in a critical path of the SGLang runtime. The scheduler component, which coordinates multimodal generation tasks across workers, uses a ZeroMQ ROUTER socket for inter-process communication. According to the anti-proof disclosure, this socket binds to 0.0.0.0 (all network interfaces) by default, meaning any host that can reach the scheduler's port can send messages.

The sink function that handles incoming ROUTER messages calls pickle.loads() on the message payload without any integrity check or type validation. Python's pickle module is notoriously unsafe for untrusted data — it can deserialize arbitrary objects and execute arbitrary code during the unpickling process via __reduce__ or __reduce_ex__ methods. An attacker who crafts a malicious pickle payload can trigger execution of system commands, drop backdoors, or exfiltrate data.

The CVSS 9.8 score reflects the combination of network exploitability (AV:N), low attack complexity (AC:L), no privileges required (PR:N), and no user interaction (UI:N). The impact on confidentiality, integrity, and availability is rated as complete (C:H/I:H/A:H).

SGLang is an open-source framework for serving large language models and multimodal models, commonly deployed in research labs, AI startups, and enterprise inference pipelines. The scheduler is a core component that must be reachable by worker nodes, and many deployments may inadvertently leave the ROUTER socket exposed to the internet due to the default binding behavior.

The anti-proof team did not publish a proof-of-concept exploit, but the underlying technique — crafting a pickle payload to execute code — is well-documented and trivial to implement. Any attacker with basic Python knowledge and network access to the scheduler port can weaponize this vulnerability.

Mitigations & Recommendations

Organizations running SGLang should take the following actions immediately:

1. Update SGLang to the latest patched version. The anti-proof disclosure indicates that the vendor has addressed the issue in a recent release. Check the SGLang GitHub repository or release notes for the specific version that fixes CVE-2026-7301.

2. Restrict network access to the scheduler's ROUTER socket. Even after patching, the socket should not be exposed to the internet. Use firewall rules or network segmentation to limit access to only trusted worker nodes and management hosts. The default 0.0.0.0 binding should be overridden in configuration to bind to a specific internal IP or Unix socket.

3. Monitor for anomalous pickle traffic. If patching cannot be performed immediately, defenders should monitor network traffic to the scheduler port for unusually large or malformed messages that could indicate exploitation attempts. Endpoint detection and response (EDR) rules can also flag processes that spawn shells or execute unexpected binaries after receiving network data.

4. Apply the principle of least privilege to the SGLang process. If the scheduler runs as root or a high-privilege user, an RCE would give attackers full control. Running the service under a dedicated, low-privilege user account limits the blast radius.

No workaround is available that fully mitigates the vulnerability without patching, as the insecure deserialization occurs before any authentication or authorization checks.