CVE-2026-109228 in SGLang
Summary
by MITRE • 10/12/2026
SGLang through 0.5.21 contains a resource budget bypass vulnerability that allows remote attackers to override GLM-V video processing limits by supplying fps, max_frames, max_tokens_per_frame and max_image_tokens in the video_url object. Attackers can set these values arbitrarily high so glm4v.py decodes every frame of high-resolution video at full size, exhausting worker memory and denying service.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in SGLang versions up to 0.5.21 represents a critical resource budget bypass that undermines the intended security controls for video processing workflows. This flaw specifically targets the GLM-V module, which is responsible for handling visual inputs within large language model applications. The core of the issue lies in how the system processes parameters passed via the video_url object during API requests. Instead of enforcing strict limits on computational resources such as frame rate and token counts, the application accepts arbitrary values for fps, max_frames, max_tokens_per_frame, and max_image_tokens from untrusted remote attackers. This lack of input validation allows malicious actors to manipulate the internal logic that governs resource allocation, effectively bypassing the safeguards designed to prevent excessive consumption of system resources.
From a technical perspective, the vulnerability exploits the direct mapping between user-supplied parameters and the video decoding engine. When an attacker supplies excessively high values for these fields, the glm4v.py script is instructed to decode every single frame of a provided high-resolution video at its full native size without any throttling or capping mechanisms in place. This behavior stands in stark contrast to secure implementations where such limits are enforced server-side regardless of client input. By forcing the system to process an unbounded number of frames, the application triggers a massive spike in memory usage as each frame is loaded into RAM for processing. The absence of checks on max_tokens_per_frame and max_image_tokens further exacerbates this issue by allowing the generation pipeline to consume disproportionate amounts of computational power during inference steps associated with visual tokens.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition against the affected service infrastructure. As worker nodes attempt to process these artificially inflated requests, their memory consumption escalates rapidly until it exceeds available physical or virtual memory limits. This leads to system instability, application crashes, or forced termination by operating system resource monitors. In cloud-native environments where SGLang is often deployed as a microservice, this can result in the failure of individual pods and potentially trigger cascading failures across the cluster if load balancers continue routing traffic to compromised instances. The ability for remote attackers to exhaust worker memory effectively renders the service unavailable to legitimate users, disrupting business operations that rely on real-time video analysis or multimodal AI capabilities.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, and specifically relates to CWE-770 regarding allocation of resources without limits. In terms of offensive security frameworks, this exploit maps directly to the MITRE ATT&CK technique T1496, Resource Hijacking, where attackers consume significant amounts of computing resources to disrupt service availability or potentially mine cryptocurrency in other contexts. The attack vector is classified as remote with low complexity, requiring only a single crafted HTTP request containing malicious parameters within the video_url object. There are no known authentication requirements for this specific bypass if the endpoint itself is publicly accessible, making it particularly dangerous in production environments where API endpoints may be exposed to external networks without sufficient rate limiting or input sanitization layers.
Mitigation strategies must focus on implementing strict server-side validation and enforcement of resource limits independent of client-supplied values. Developers should hardcode maximum acceptable thresholds for fps, max_frames, max_tokens_per_frame, and max_image_tokens within the glm4v.py module rather than relying solely on user-provided data. Additionally, integrating a web application firewall or API gateway with rate limiting capabilities can help detect and block requests that exhibit patterns consistent with resource exhaustion attacks. It is also advisable to implement memory monitoring alerts that trigger automatic scaling or request rejection when worker nodes approach critical utilization thresholds. Upgrading to patched versions of SGLang where these limits are properly enforced by the framework itself remains the most effective long-term solution, ensuring that all video processing operations adhere to predefined security boundaries regardless of external input manipulation.