Summary
SGLang contains a code injection vulnerability in the dumper filter evaluation logic, where crafted filter expressions can escape an eval()-based sandbox through Python introspection features.
When the dumper server is enabled and its configuration endpoint is reachable, an unauthenticated remote attacker may execute Python code in the scheduler process during a subsequent forward pass.
SGLang contains a code injection vulnerability in the dumper filter evaluation logic, where crafted filter expressions can escape an eval()-based sandbox through Python introspection features.
When the dumper server is enabled and its configuration endpoint is reachable, an unauthenticated remote attacker may execute Python code in the scheduler process during a subsequent forward pass.
Affected context
The vulnerability affects SGLang deployments that:
- Use the affected dumper configuration functionality
- Enable the dumper server by setting
DUMPER_SERVER_PORT - Expose the unauthenticated
/dumper/configureendpoint to an attacker - Evaluate submitted filter expressions during scheduler operation
Exploitation depends on the endpoint being reachable and the crafted expression being processed by _evaluate_filter().
The vulnerability affects SGLang deployments that:
- Use the affected dumper configuration functionality
- Enable the dumper server by setting
DUMPER_SERVER_PORT - Expose the unauthenticated
/dumper/configureendpoint to an attacker - Evaluate submitted filter expressions during scheduler operation
Exploitation depends on the endpoint being reachable and the crafted expression being processed by _evaluate_filter().
Exploit preconditions
- Attack surface: Network-accessible dumper configuration endpoint
- Required access: Typically no authentication when the endpoint is exposed without additional access controls
- Trigger point: Submission of a crafted filter expression followed by processing on a scheduler forward pass
- Why exploitation is possible: User-controlled expressions reach Python
eval()logic, and the intended sandbox can be bypassed through accessible object and function metadata such asre.search.__globals__
- Attack surface: Network-accessible dumper configuration endpoint
- Required access: Typically no authentication when the endpoint is exposed without additional access controls
- Trigger point: Submission of a crafted filter expression followed by processing on a scheduler forward pass
- Why exploitation is possible: User-controlled expressions reach Python
eval()logic, and the intended sandbox can be bypassed through accessible object and function metadata such asre.search.__globals__
Why this happens
The underlying issue is the evaluation of attacker-controlled filter expressions with Python eval() as though the execution environment were safely restricted.
Python objects can expose references to global namespaces and other runtime capabilities. If those capabilities remain reachable from the evaluation context, an expression may escape the intended restrictions and invoke arbitrary Python functionality. This behavior maps to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code.
The underlying issue is the evaluation of attacker-controlled filter expressions with Python eval() as though the execution environment were safely restricted.
Python objects can expose references to global namespaces and other runtime capabilities. If those capabilities remain reachable from the evaluation context, an expression may escape the intended restrictions and invoke arbitrary Python functionality. This behavior maps to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code.
Potential impact
- An attacker may execute arbitrary Python code in the scheduler process.
- The attacker could access process memory, environment variables, or local files.
- The application runtime may be modified or disrupted.
- Credentials available to the scheduler process could be exposed.
- The compromised process could be used for further movement within the deployment environment.
- An attacker may execute arbitrary Python code in the scheduler process.
- The attacker could access process memory, environment variables, or local files.
- The application runtime may be modified or disrupted.
- Credentials available to the scheduler process could be exposed.
- The compromised process could be used for further movement within the deployment environment.
General mitigation guidance
Mitigation generally focuses on removing dynamic code evaluation from request-driven filter processing and reducing exposure of administrative endpoints.
Common defensive patterns include:
- Replace
eval()with a purpose-built filter parser or a strict expression language. - Permit only explicitly defined operators, fields, and value types through an allowlist.
- Avoid relying on restricted globals or locals as a security boundary for Python evaluation.
- Require authentication and authorization for dumper configuration operations.
- Bind administrative interfaces to restricted network scopes where practical.
- Run scheduler processes with least privilege and minimal access to secrets and host resources.
- Treat configuration and filter expressions as untrusted input until fully parsed and validated.
Mitigation generally focuses on removing dynamic code evaluation from request-driven filter processing and reducing exposure of administrative endpoints.
Common defensive patterns include:
- Replace
eval()with a purpose-built filter parser or a strict expression language. - Permit only explicitly defined operators, fields, and value types through an allowlist.
- Avoid relying on restricted globals or locals as a security boundary for Python evaluation.
- Require authentication and authorization for dumper configuration operations.
- Bind administrative interfaces to restricted network scopes where practical.
- Run scheduler processes with least privilege and minimal access to secrets and host resources.
- Treat configuration and filter expressions as untrusted input until fully parsed and validated.
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis rules identifying
eval(),exec(), or equivalent dynamic evaluation on request-derived data. - Code review checks for sandbox implementations based only on restricted globals, locals, or built-in removal.
- Taint analysis tracing HTTP parameters into expression evaluators and subprocess or file-access APIs.
- Monitoring requests to dumper or administrative endpoints, including unusual filter syntax and unexpected configuration changes.
- Network policy checks confirming that optional diagnostic interfaces are not broadly exposed.
Automated security scanners and code-review tools can help identify dynamic evaluation paths, but findings should be validated against the actual request and execution flow.
Organizations commonly detect this class of issue through:
- Static analysis rules identifying
eval(),exec(), or equivalent dynamic evaluation on request-derived data. - Code review checks for sandbox implementations based only on restricted globals, locals, or built-in removal.
- Taint analysis tracing HTTP parameters into expression evaluators and subprocess or file-access APIs.
- Monitoring requests to dumper or administrative endpoints, including unusual filter syntax and unexpected configuration changes.
- Network policy checks confirming that optional diagnostic interfaces are not broadly exposed.
Automated security scanners and code-review tools can help identify dynamic evaluation paths, but findings should be validated against the actual request and execution flow.
