CVE-2026-93838 in SGLang
Summary
by MITRE • 09/18/2026
SGLang versions through 0.5.20 contain an unbounded memory allocation vulnerability in handle_staging_req() that fails to validate chunk_idx from ZMQ STAGING_REQ frames in prefill/decode disaggregation deployments. Attackers with access to the decode engine's internal ZMQ rank port can send a frame with an extremely large chunk_idx value, causing the scheduler to allocate memory until the system runs out and terminates the process.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in SGLang versions through 0.5.20 represents a critical unbounded memory allocation flaw located within the handle_staging_req function of the prefill/decode disaggregation architecture. This component is responsible for managing data staging between different engine components, specifically handling requests that arrive via ZeroMQ STAGING_REQ frames. The core technical deficiency lies in the complete absence of validation logic for the chunk_idx parameter extracted from these incoming network frames. In a properly secured system, any index or identifier received over a network interface must be rigorously validated against known bounds to ensure it corresponds to valid memory regions within the application's address space. By failing to check whether the provided chunk_idx falls within acceptable limits, the software allows an attacker to supply arbitrary integer values that bypass internal safety checks entirely.
The operational impact of this flaw is severe and directly leads to resource exhaustion on the affected system. When a malicious actor sends a STAGING_REQ frame containing an extremely large or negative chunk_idx value, the scheduler interprets this input as a valid request for memory allocation. Consequently, the application attempts to allocate a massive amount of contiguous memory corresponding to the invalid index size. This action rapidly depletes available system resources, including RAM and swap space. As the operating system struggles to satisfy these excessive allocation requests, performance degradation occurs across all running processes. Eventually, the system reaches its resource limit, causing the scheduler process to terminate abruptly due to an out-of-memory condition or being killed by the kernel's Out-Of-Memory killer mechanism. This results in a complete denial of service for any inference tasks relying on this SGLang instance.
From a threat modeling perspective, this vulnerability is exploitable only by attackers who have achieved network access to the decode engine's internal ZeroMQ rank port. While this restricts the attack surface compared to remote code execution vulnerabilities accessible from the public internet, it remains highly dangerous in environments where lateral movement has occurred or where trusted but compromised services can communicate with the inference engines. The exploitation does not require complex payload construction beyond sending a single malformed message with an oversized index field, making automated scanning and exploitation trivial for any actor with access to that specific network segment.
This vulnerability aligns closely with CWE-400, which describes uncontrolled resource consumption leading to denial of service conditions. Furthermore, the mechanism of exploiting memory allocation through invalid input parameters is characteristic of CWE-789, or Uncontrolled Memory Allocation. In terms of adversary tactics as defined by MITRE ATT&CK, this flaw facilitates Resource Hijacking under the Impact tactic category, where an attacker consumes system resources to disrupt availability rather than stealing data or executing code directly. The lack of boundary checks on network-derived indices is a common pattern in distributed systems that prioritize performance over strict input validation during high-throughput operations.
To mitigate this vulnerability, immediate patching to SGLang version 0.5.21 or later is required, as the developers have addressed the missing validation logic within the handle_staging_req function. In addition to upgrading software components, organizations should implement network segmentation strategies that restrict access to internal ZeroMQ ports used for inter-engine communication. These ports should not be exposed to untrusted networks and must be firewalled to allow traffic only from authorized prefill engine instances. Implementing strict input validation at the application layer is also essential; developers must ensure that all indices, offsets, and sizes derived from external inputs are validated against maximum allowable bounds before being used for memory operations. Monitoring tools should be configured to alert on sudden spikes in memory usage or abnormal termination of scheduler processes, which may indicate ongoing exploitation attempts targeting this specific flaw.