CVE-2026-112270 in SGLang
Summary
by MITRE • 10/19/2026
SGLang through 0.5.22 with the Mooncake disaggregation backend contains an uncontrolled memory allocation vulnerability in handle_staging_rsp() that lets unauthenticated network-adjacent attackers exhaust Prefill memory. Attackers can obtain the rank address from the /route endpoint and send STAGING_RSP messages with huge chunk_idx values under fresh room IDs, causing the scheduler to be OOM-killed.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in SGLang versions up to 0.5.22 involves a critical uncontrolled memory allocation flaw within the Mooncake disaggregation backend, specifically located in the handle_staging_rsp function. This architectural component is designed to manage resource distribution across distributed systems, but it fails to adequately validate input parameters before initiating memory operations. The core technical deficiency lies in the lack of bounds checking for chunk_idx values received via STAGING_RSP messages. When an attacker sends a request with an excessively large or malformed chunk index under a fresh room ID, the system attempts to allocate memory based on this untrusted value without verifying its feasibility against available resources. This oversight allows for significant resource consumption that far exceeds intended limits, leading directly to out-of-memory conditions within the Prefill stage of the processing pipeline.
From an operational perspective, this flaw enables denial-of-service attacks by any network-adjacent actor who can interact with the service endpoints. The attack vector is relatively straightforward and does not require authentication, significantly lowering the barrier for exploitation. An adversary first queries the /route endpoint to discover valid rank addresses within the distributed system. Armed with this information, they construct malicious STAGING_RSP messages containing oversized chunk indices. Upon processing these requests, the scheduler attempts to fulfill memory allocation demands that are physically impossible or excessively large relative to system capacity. The result is rapid exhaustion of available memory resources, causing the operating system's out-of-memory killer to terminate the SGLang process. This leads to service disruption and potential data loss if state was not persisted externally before termination.
This vulnerability aligns with CWE-789: Uncontrolled Memory Allocation, as it involves allocating excessive amounts of memory based on untrusted input without proper validation or limits. In terms of attack classification under the MITRE ATT&CK framework, this behavior corresponds to T1499: Endpoint Denial of Service, specifically through resource exhaustion techniques that target application-level services rather than just network bandwidth. The lack of authentication requirement places it in a high-risk category for public-facing APIs or internal services exposed within trusted networks where lateral movement is possible after initial access.
Mitigation strategies should prioritize immediate patching to version 0.5.23 or later, which addresses the validation logic in handle_staging_rsp(). In environments where upgrading is not immediately feasible, network-level controls such as rate limiting and strict input size restrictions on STAGING_RSP messages can help mitigate exploitation attempts. Additionally, implementing memory usage monitoring and alerting for sudden spikes in allocation requests may provide early detection of ongoing attacks. It is also recommended to review the /route endpoint access policies to ensure that rank address discovery is restricted to authorized components only, thereby reducing the attack surface available to potential adversaries.