SGLang CVE-2026-93034: disabling pickle IPC is insufficient

CVE-2026-93034 affecting SGLang was published on 8 October. The CERT/CC record describes unsafe deserialisation in ZeroMQ messaging that remains reachable with SGLANG_USE_PICKLE_IPC disabled. Remote exploitation requires data-parallel attention enabled and a non-loopback --dist-init-addr. The affected range includes releases through v0.5.20; the record examined does not identify a fixed version. Source: the CVE record published by CERT/CC.

Breachroad’s conclusion: teams operating model servers should verify configuration and the reachability of communication between nodes. An environment flag alone is insufficient evidence that the described path has been removed. Not every SGLang deployment meets the remote exploitation conditions, and a non-loopback address does not automatically mean internet exposure.

What the code shows

In the source tagged v0.5.20, the msgpack decoder can return a PickleWrapper object. _maybe_unwrap_pickle passes its data to pickle.loads. The receiving branch that uses msgpack still invokes that function when the pickle IPC flag is disabled.

This is a reading of a specific source file, rather than a test of every deployment configuration. Our interpretation is that a review must follow the complete path into deserialisation instead of inferring safety from the outer message format. In this flow, data wrapped in msgpack can invoke another decoding mechanism.

The Python documentation warns that unpickling untrusted data can execute code. In our assessment, access to a process’s messaging channel therefore deserves attention as an authority boundary, rather than only a model server performance concern.

Three findings before closing the ticket

The following steps are Breachroad’s recommendations for administrators and MLOps teams:

1. Identify the running component. Record the version of the package or image actually in use, the process configuration and the service owner. Do not rely solely on a dependency file in the repository: production may have a different update history.
2. Identify permitted senders. Establish which systems can reach communication channels between nodes. Include other workloads in the cluster, administrative connections and shared environments. Calling a network internal does not establish its actual access boundaries.
3. Document the risk reduction decision. Define the expected nodes, restrict other connections with appropriate network rules and confirm that required functions still work. Record an accountable owner and a date to review further information from the project.

We do not recommend a particular upgrade as a fix because the record examined does not identify one. When choosing a release, require confirmation from the project that it addresses this issue, alongside verification of the relevant path in your environment. A higher version number alone does not explain what changed.

The practical output should distinguish the running version, reachable systems, network restrictions and evidence of a code fix. These are separate findings. Leaving an unresolved item visible makes the next review more useful than marking the entire ticket complete because one setting was changed.

Same model, different access boundaries

Consider two teams serving the same model. The first can identify the service nodes and demonstrate that worker communication is restricted to them. The second shares a network with other departments’ applications and has no list of permitted senders. This is a training example, rather than a description of actual victims.

Our recommendation for the second team is to establish reachability and who owns its restrictions, then verify the change. The first team still needs to assess the vulnerability. Restricting access and correcting vulnerable code provide different evidence, and both should be visible in the ticket.

Handling suspected compromise

If the review identifies unexpected connections or process activity, invoke your incident handling procedure. We recommend preserving logs, configuration and a timeline of service accessibility, then establishing which resources the service account could access. Isolation and credential decisions should reflect that scope. Removing one connection does not explain all earlier activity.

The vulnerability is a reminder that AI security also includes server processes, networks and permissions. For broader context, read our guide to LLM security in business. Teams deploying models can practise these decisions in our cybersecurity and secure AI training for organisations.