Summary
SGLang contains an unsafe deserialization vulnerability in its ZeroMQ message decoder, which unconditionally processes PickleWrapper payloads with Python's pickle.loads() without authentication or type allowlisting. When data-parallel attention is enabled with a non-loopback distribution address, a remote attacker may achieve arbitrary code execution through the message-processing path, including when the pickle IPC setting is disabled.
SGLang contains an unsafe deserialization vulnerability in its ZeroMQ message decoder, which unconditionally processes PickleWrapper payloads with Python's pickle.loads() without authentication or type allowlisting. When data-parallel attention is enabled with a non-loopback distribution address, a remote attacker may achieve arbitrary code execution through the message-processing path, including when the pickle IPC setting is disabled.
Affected context
The issue occurs in SGLang deployments that use the ZeroMQ communication path and process messages through the decoder's msgpack or PickleWrapper handling logic. Risk is higher when data-parallel attention is enabled and the distribution initialization address is reachable beyond the local host; disabling the dedicated pickle IPC option alone may not remove the vulnerable deserialization path.
The issue occurs in SGLang deployments that use the ZeroMQ communication path and process messages through the decoder's msgpack or PickleWrapper handling logic. Risk is higher when data-parallel attention is enabled and the distribution initialization address is reachable beyond the local host; disabling the dedicated pickle IPC option alone may not remove the vulnerable deserialization path.
Exploit preconditions
- Attack surface: SGLang's ZeroMQ inter-process or distributed messaging endpoint
- Required access: Ability to send or influence messages received by the affected SGLang process; remote access may be sufficient when the distribution address is externally reachable
- Trigger point: ZMQ message decoding and
_maybe_unwrap_pickleprocessing - Deployment condition: Data-parallel attention is enabled with a non-loopback
--dist-init-addrsetting - Why exploitation is possible: PickleWrapper payloads are deserialized with
pickle.loads()without authentication or an explicit type allowlist
- Attack surface: SGLang's ZeroMQ inter-process or distributed messaging endpoint
- Required access: Ability to send or influence messages received by the affected SGLang process; remote access may be sufficient when the distribution address is externally reachable
- Trigger point: ZMQ message decoding and
_maybe_unwrap_pickleprocessing - Deployment condition: Data-parallel attention is enabled with a non-loopback
--dist-init-addrsetting - Why exploitation is possible: PickleWrapper payloads are deserialized with
pickle.loads()without authentication or an explicit type allowlist
Why this happens
The vulnerability results from treating serialized message content as trusted executable object data. Python pickle deserialization can invoke object reconstruction behavior during loading, so applying pickle.loads() to attacker-influenced bytes permits arbitrary code execution rather than merely decoding inert data. This maps to CWE-502: Deserialization of Untrusted Data; the absence of authentication, integrity protection, and type restrictions allows the message decoder to process unsafe objects, including through the msgpack path.
The vulnerability results from treating serialized message content as trusted executable object data. Python pickle deserialization can invoke object reconstruction behavior during loading, so applying pickle.loads() to attacker-influenced bytes permits arbitrary code execution rather than merely decoding inert data. This maps to CWE-502: Deserialization of Untrusted Data; the absence of authentication, integrity protection, and type restrictions allows the message decoder to process unsafe objects, including through the msgpack path.
Potential impact
- An attacker could execute arbitrary code in the SGLang process context.
- The attacker may access or modify model data, inputs, outputs, and runtime secrets.
- A compromised worker could be used for lateral movement within the serving or cluster environment.
- The vulnerability could enable service disruption, data manipulation, or model-serving abuse.
- An attacker could execute arbitrary code in the SGLang process context.
- The attacker may access or modify model data, inputs, outputs, and runtime secrets.
- A compromised worker could be used for lateral movement within the serving or cluster environment.
- The vulnerability could enable service disruption, data manipulation, or model-serving abuse.
General mitigation guidance
Mitigation generally focuses on removing executable deserialization from network-facing message paths and reducing trust in serialized data.
Common defensive patterns include:
- Replacing pickle-based transport with inert, schema-defined formats that do not reconstruct arbitrary objects.
- Enforcing strict message schemas and explicit type allowlists before any object conversion.
- Applying authentication and integrity protection to distributed messages.
- Binding communication endpoints to private interfaces unless broader exposure is required.
- Running workers with least privilege, isolated credentials, and restricted network egress.
- Treating configuration switches that disable one serialization path as insufficient unless every alternate decoder path is independently safe.
Mitigation generally focuses on removing executable deserialization from network-facing message paths and reducing trust in serialized data.
Common defensive patterns include:
- Replacing pickle-based transport with inert, schema-defined formats that do not reconstruct arbitrary objects.
- Enforcing strict message schemas and explicit type allowlists before any object conversion.
- Applying authentication and integrity protection to distributed messages.
- Binding communication endpoints to private interfaces unless broader exposure is required.
- Running workers with least privilege, isolated credentials, and restricted network egress.
- Treating configuration switches that disable one serialization path as insufficient unless every alternate decoder path is independently safe.
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving
pickle.loads(), pickle-compatible wrappers, and deserialization of network-controlled bytes. - Code-review signals such as generic object reconstruction, missing message authentication, or parsers that accept multiple serialization paths without equivalent validation.
- Runtime telemetry for unexpected ZMQ peers, unusual distributed initialization addresses, and anomalous message types or worker process behavior.
- Policy enforcement that prohibits executable serialization in network protocols and requires schema validation and authenticated transport.
- Automated security review tools can help identify unsafe deserialization APIs and untrusted data flows, but findings should be validated against the deployment topology.
Organizations can look for:
- Static-analysis findings involving
pickle.loads(), pickle-compatible wrappers, and deserialization of network-controlled bytes. - Code-review signals such as generic object reconstruction, missing message authentication, or parsers that accept multiple serialization paths without equivalent validation.
- Runtime telemetry for unexpected ZMQ peers, unusual distributed initialization addresses, and anomalous message types or worker process behavior.
- Policy enforcement that prohibits executable serialization in network protocols and requires schema validation and authenticated transport.
- Automated security review tools can help identify unsafe deserialization APIs and untrusted data flows, but findings should be validated against the deployment topology.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| m00dy. | m00dy.sh/ |
