CVE-2026-93838: SGLang Unbounded Memory Allocation DoS

CVE-2026-93838 Overview

CVE-2026-93838 is an unbounded memory allocation vulnerability [CWE-770] affecting SGLang versions through 0.5.20. The flaw resides in the handle_staging_req() function, which fails to validate the chunk_idx field parsed from ZMQ STAGING_REQ frames. In prefill/decode disaggregation deployments, an attacker with network access to the decode engine's internal ZMQ rank port can submit a frame containing an oversized chunk_idx value. The scheduler then allocates memory proportional to the attacker-controlled index until the host exhausts available memory and the process is terminated by the operating system.

Critical Impact
A single crafted ZMQ frame can drive the SGLang scheduler to out-of-memory termination, disrupting inference availability for LLM serving infrastructure.

Affected Products

SGLang versions through 0.5.20
Deployments using prefill/decode disaggregation with exposed ZMQ rank ports
LLM inference clusters running the SGLang scheduler with handle_staging_req() enabled

Discovery Timeline

2026-09-18 - CVE-2026-93838 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93838

Vulnerability Analysis

SGLang is an inference framework for large language models. In disaggregated deployments, prefill and decode workloads communicate over ZeroMQ (ZMQ) sockets bound to internal rank ports. The handle_staging_req() handler in staging_handler.py processes STAGING_REQ frames and uses a chunk_idx integer supplied by the peer to index into or size internal buffers.

Because the handler does not enforce upper bounds on chunk_idx, the scheduler treats attacker-controlled values as trustworthy. Supplying a large integer causes the scheduler to attempt an allocation whose size scales with that integer. The Linux out-of-memory (OOM) killer subsequently terminates the SGLang process, halting inference for every tenant sharing that decode engine.

This is a resource exhaustion condition classified under [CWE-770: Allocation of Resources Without Limits or Throttling]. Exploitation requires network reachability to the decode engine's ZMQ rank port but no authentication, because internal ZMQ channels in SGLang disaggregation lack peer verification.

Root Cause

The handler at staging_handler.py L848-L860 deserializes the STAGING_REQ frame and uses chunk_idx directly for buffer sizing. No max_chunks policy or bounds check is enforced before allocation.

Attack Vector

An attacker with network access to the decode engine's internal ZMQ rank port sends a single STAGING_REQ frame containing an extremely large chunk_idx field. The vulnerability manifests during frame handling in conn.py L1636-L1640 and the allocation path in staging_handler.py L781. No authentication, prior session, or user interaction is required. Refer to the VulnCheck Advisory for the full technical write-up.

Detection Methods for CVE-2026-93838

Indicators of Compromise

Unexpected SGLang scheduler crashes with OOM-killer entries in dmesg or journalctl referencing the SGLang Python process.
Sudden memory pressure spikes on decode engine hosts correlated with inbound ZMQ traffic on rank ports.
ZMQ STAGING_REQ frames originating from unexpected source addresses outside the trusted rank mesh.

Detection Strategies

Inspect application logs for handle_staging_req() invocations followed by process termination without a normal shutdown sequence.
Deploy network monitoring on ZMQ rank ports to flag frames with abnormally large integer fields in the STAGING_REQ payload.
Correlate host-level OOM events with the SGLang process identifier and inbound network flows to identify targeted denial-of-service attempts.

Monitoring Recommendations

Track resident set size (RSS) and virtual memory growth of the SGLang scheduler process at high sampling rates.
Alert on ZMQ traffic to disaggregation rank ports from sources outside the defined worker CIDR range.
Ingest inference host telemetry into a centralized data lake to enable retrospective analysis of memory-exhaustion patterns across the fleet.

How to Mitigate CVE-2026-93838

Immediate Actions Required

Restrict network access to SGLang ZMQ rank ports so only trusted prefill and decode workers can connect.
Place decode engines behind a private VPC or overlay network with strict ingress firewall rules.
Monitor decode engine hosts for OOM events and configure automatic process restart with rate limiting to prevent repeated abuse.

Patch Information

No fixed version is identified in the NVD record at the time of publication. Track the upstream fix through GitHub Issue #39764 and the SGLang project repository for a release that validates chunk_idx bounds in handle_staging_req().

Workarounds

Bind ZMQ rank sockets to loopback or private management interfaces rather than routable addresses.
Enforce network policies (for example, Kubernetes NetworkPolicy or cloud security groups) that whitelist only peer ranks on the ZMQ port.
If disaggregation is not required, run SGLang in a co-located prefill/decode configuration that does not expose staging endpoints.
Apply a local patch that rejects STAGING_REQ frames where chunk_idx exceeds a deployment-specific maximum before allocation occurs.

bash

# Example: restrict ZMQ rank port to trusted peers using iptables
ZMQ_RANK_PORT=<decode_rank_port>
TRUSTED_CIDR=<worker_subnet>/24
iptables -A INPUT -p tcp --dport ${ZMQ_RANK_PORT} -s ${TRUSTED_CIDR} -j ACCEPT
iptables -A INPUT -p tcp --dport ${ZMQ_RANK_PORT} -j DROP