CVE-2026-111391 in SGLang
Summary
by MITRE • 10/16/2026
SGLang 0.5.10 through 0.5.22 contains a code injection vulnerability in _evaluate_filter() that allows remote attackers to execute Python code by escaping the eval() sandbox through re.search __globals__. Attackers can send a crafted filter expression to the unauthenticated /dumper/configure endpoint when DUMPER_SERVER_PORT is set, running code in the scheduler process on the next forward pass.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in SGLang versions 0.5.10 through 0.5.22 represents a critical server-side request forgery and remote code execution flaw rooted in improper neutralization of special elements used within an expression or string, commonly categorized under CWE-94 as Improper Control of Generation of Code. The core technical defect resides within the evaluate_filter() function, which is designed to process filter expressions provided by users. This function utilizes Python's eval() mechanism to interpret these inputs; however, it fails to adequately sandbox the execution environment or restrict access to dangerous built-in attributes and modules. Specifically, an attacker can exploit the __globals_ attribute of the re.search object to bypass the intended restrictions imposed by the evaluation context. By carefully crafting a filter expression that accesses this global namespace, the malicious actor gains read and write access to variables and functions within the Python interpreter's scope, effectively breaking out of any sandboxed environment designed to limit code execution capabilities.
From an operational perspective, this vulnerability allows unauthenticated remote attackers to achieve arbitrary code execution on the host system running SGLang. The attack vector is particularly dangerous because it targets the /dumper/configure endpoint, which must be exposed when the DUMPER_SERVER_PORT environment variable is set. This configuration implies that in many production or development setups where this feature is enabled, the vulnerable endpoint may be accessible over a network without requiring authentication credentials. Once an attacker sends their crafted payload to this endpoint, the malicious code execution occurs within the scheduler process during its next forward pass. This means the impact extends beyond simple data leakage; it allows for full control of the application's runtime environment, potentially leading to complete system compromise depending on the privileges under which the SGLang service is operating.
The implications of such a vulnerability are severe in the context of modern machine learning infrastructure and large language model serving platforms. Since SGLang is often deployed in environments handling sensitive data or critical inference workloads, unauthorized code execution can lead to data exfiltration, modification of model weights or configurations, denial of service through resource exhaustion, or further lateral movement within a network if the host system is part of a larger cluster. The ability to escape sandboxed evaluation contexts highlights a fundamental risk in dynamically evaluating user-supplied strings as code, a pattern that should generally be avoided in security-sensitive applications unless strictly necessary and heavily constrained with allow-lists for permitted modules and functions rather than relying on restrictive blocklists or basic sandboxes which can often be bypassed using reflection techniques like _globals_.
To mitigate this vulnerability, organizations running SGLang versions 0.5.10 through 0.5.22 should immediately upgrade to a patched version where the evaluate_filter() function has been hardened against such escape vectors. If upgrading is not immediately feasible, it is critical to ensure that the DUMPER_SERVER_PORT environment variable is not set in production environments unless absolutely necessary for specific debugging or internal tooling purposes. When this feature must be enabled, access to the /dumper/configure endpoint should be strictly restricted using network-level controls such as firewalls or reverse proxy configurations that limit connectivity to trusted IP addresses only. Additionally, implementing input validation and sanitization strategies that reject any filter expressions containing references to dunder attributes like __globals_ can provide a temporary layer of defense, although upgrading remains the most effective remediation strategy. Security teams should also monitor for signs of unauthorized configuration changes or unusual process behavior in systems running these vulnerable versions, as such activity may indicate an active exploitation attempt aligned with techniques described in MITRE ATT&CK under command and script interpretation categories.