SGLang's ZMQ decoder still unpickles attacker data with pickle IPC disabled. Multi-node DP-attention clusters are open to unauthenticated RCE; no fix yet.
SGLang, the open-source LLM serving engine, has a critical deserialization flaw, CVE-2026-93034 (GHSA-w4hv-c72g-pqx6, CVSS 9.8). Its internal ZeroMQ message decoder still runs pickle.loads() on PickleWrapper payloads when the SGLANG_USE_PICKLE_IPC setting is disabled. Operators who ran multi-node data-parallel attention with a non-loopback bind address are exposed to unauthenticated remote code execution. The advisory was published on 8 October 2026. No fixed version has been confirmed.
Who is affected
The advisory lists affected and patched versions as unknown and offers no workaround. The researcher's runtime test used stock v0.5.18. The researcher also inspected the source of v0.5.20 and main on 1 October and found the same primitives. Our own check of the v0.5.22 tag (released 19 October) shows _maybe_unwrap_pickle still calling pickle.loads(obj.data) on a PickleWrapper. That is a source reading, not a runtime test. Treat every release up to v0.5.22 as potentially vulnerable until the maintainers say otherwise.
Exposure takes three conditions together: data-parallel attention enabled, a non-loopback distribution address (--dist-init-addr), and a network path to the receiver's port. The default single-node layout uses Unix-domain sockets, which stay on the host. The researcher did not show delivery through the HTTP API, which stayed on loopback in that setup.
Technical detail
The flaw is CWE-502, deserialization of untrusted data. SGLANG_USE_PICKLE_IPC defaults to true, and in that mode the receive function uses recv_pyobj, which unpickles raw messages. Setting it to false switches to a MessagePack decoder. That decoder accepts a PickleWrapper as a top-level message, and _maybe_unwrap_pickle then calls pickle.loads on its bytes. There is no type allowlist and no peer authentication. The dispatcher validates the object only after it has been reconstructed, so side effects during unpickling happen before any rejection.
Why setting SGLANG_USE_PICKLE_IPC=false is not a mitigation.
Why setting SGLANG_USE_PICKLE_IPC=false is not a mitigation.
The write-up, tracked as CRUCIBLE-2026-131 and CERT/CC VU#765030, tested six fresh starts on two A100 GPUs (TP=2, DP=2) with Qwen3-30B-A3B. Every crafted message wrote exactly one marker file, and its PID matched the receiver. A bare connection wrote none. No exploit code is published, and the author has seen no exploitation in the wild. The advisory lists an EPSS of 0.46%.
Timeline
CERT/CC received the report on 14 July 2026 and confirmed code execution on 17 September, when the CVE was assigned. SGLang v0.5.21 shipped on 2 October. The write-up appeared on 7 October and the CVE record on 8 October.
What defenders should do
- Find deployments that use data-parallel attention with a non-loopback
--dist-init-addr. - Restrict the receiver ports with host firewalls or security groups so that only cluster peers can reach them. Use a private network segment for multi-node traffic.
- Do not rely on
SGLANG_USE_PICKLE_IPC=falseas a mitigation. - Watch the SGLang releases and the GHSA for a patched version. Upgrade once one is named.
- Check hosts for unexpected child processes or files created by the SGLang worker processes.
The researcher's proposed repair is to drop the raw pickle path and PickleWrapper from any peer-writable transport, use a typed data-only wire format validated before dispatch, and authenticate peers. That is the researcher's proposal, not a vendor fix.