Is a default SGLang install exposed to CVE-2026-111391?

A default SGLang install is not exposed, because the dumper's server_port field ships as -1 and the HTTP server never starts. Exposure begins when an operator sets DUMPER_SERVER_PORT, which developers do when dumping tensors to debug a model. Once that port listens, the reporter states the /dumper/configure route accepts callers without credentials unless an admin_api_key is configured.

Which SGLang versions does CVE-2026-111391 affect, and is there a patch?

VulnCheck lists SGLang 0.5.10 through 0.5.22 as affected and names no fixed release. A community pull request, 44205, replaced eval() with an AST-based evaluator that blocks dunder attribute access, but a maintainer closed it unmerged on October 14 while blocking its author for opening 37 pull requests in two days. Operators should disable the dumper port rather than wait for a release.

How was the SGLang dumper flaw proven?

The reporter reproduced the flaw on SGLang v0.5.19, on an A100 80GB GPU under Python 3.12.3. After posting a crafted filter to /dumper/configure and sending a normal /generate request, the scheduler process wrote a marker file, which showed that caller-supplied Python ran outside the eval sandbox. The filter was set to evaluate false, so no tensor dump was saved.

MEDVulnerability

SGLang: a debug endpoint runs caller Python in the scheduler process

SGLang's debug dumper turns a caller's filter string into Python code, so whoever reaches the dumper port runs code in the scheduler.

October 14, 2026 · SGLang · Research by Jiapeng Li, Jiajia Liu, Qiang Fu, Jiadai Wang

CVE-2026-111391

MEDVulnerability

SGLang's debug dumper evaluates a caller-supplied filter string with Python eval(), so a request to /dumper/configure can run code in the scheduler process. No fixed release exists, and the dumper server is off by default.

01What happened

Four researchers reported an eval injection in the debug dumper of SGLang, an open-source inference framework hosted by LMSYS, as issue 44188 on the project's own tracker. VulnCheck assigned a CVE and published its advisory two days later, rating the flaw critical. SGLang's maintainers have not answered the issue.

02How it works

The dumper's _evaluate_filter() hands a caller-supplied filter string to Python's eval(). Clearing __builtins__ does not contain the expression, because the exposed re.search object reaches the module globals through __globals__ and from there __import__, the classic eval sandbox escape. A POST to /dumper/configure stores the filter, and the escape executes inside the scheduler process on the next forward pass.

03Who is affected

Only SGLang deployments that start the dumper HTTP server are exposed, and its server_port field ships as -1, so the endpoint does not listen in a normal install. The reporter reached it on v0.5.19 with DUMPER_SERVER_PORT set to reuse, and states the route accepts callers with no credentials when no admin_api_key is configured.

04What to do

Leave the SGLang dumper HTTP server off, and check running deployments for DUMPER_SERVER_PORT in their environment or launch scripts. Configure an admin_api_key so the dumper's ADMIN_OPTIONAL routes demand one, and keep any dumper port unreachable from the network.

Questions people ask

Is a default SGLang install exposed to CVE-2026-111391?: A default SGLang install is not exposed, because the dumper's server_port field ships as -1 and the HTTP server never starts. Exposure begins when an operator sets DUMPER_SERVER_PORT, which developers do when dumping tensors to debug a model. Once that port listens, the reporter states the /dumper/configure route accepts callers without credentials unless an admin_api_key is configured.
Which SGLang versions does CVE-2026-111391 affect, and is there a patch?: VulnCheck lists SGLang 0.5.10 through 0.5.22 as affected and names no fixed release. A community pull request, 44205, replaced eval() with an AST-based evaluator that blocks dunder attribute access, but a maintainer closed it unmerged on October 14 while blocking its author for opening 37 pull requests in two days. Operators should disable the dumper port rather than wait for a release.
How was the SGLang dumper flaw proven?: The reporter reproduced the flaw on SGLang v0.5.19, on an A100 80GB GPU under Python 3.12.3. After posting a crafted filter to /dumper/configure and sending a normal /generate request, the scheduler process wrote a marker file, which showed that caller-supplied Python ran outside the eval sandbox. The filter was set to evaluate false, so no tensor dump was saved.

Sources 4 links, all fetched

1github.comSGLang Issue 44188
2vulncheck.comVulnCheck Advisory
3github.comDumper Source
4github.comClosed Fix PR