SGLang debug feature lets attackers run code on AI inference servers — no fix yet, keep it switched off

A newly disclosed flaw in SGLang, a popular open-source engine for serving large language models, lets anyone who can reach an optional debugging endpoint run their own code on the server. It is tracked as CVE-2026-111391 and affects versions 0.5.10 through 0.5.22. The feature is off by default and there is no patched release yet, so the action for most teams is simple: make sure the DUMPER_SERVER_PORT setting is not set on any SGLang server you run.

What happened, in plain English

SGLang is a "serving framework": the software that loads a large language model (LLM) onto GPU servers and answers requests from applications, much like a web server answers requests for web pages. Its GitHub page describes it as "a high-performance serving framework for large language models and multimodal models", and the project says it "serves production workloads across AI labs, cloud platforms, enterprises, and universities". The repository has more than 37,000 stars.

To help engineers debug models, SGLang includes a tool called the dumper. When switched on, it saves the internal numbers the model produces as it works, so a developer can see what went wrong in a specific layer. Because saving everything would be enormous, you can give the dumper a short filter, for example "only layers 0 to 3".

The problem is how that filter is read. SGLang hands the filter text to Python's eval() function, which runs text as program code. The developers tried to make this safe by removing Python's built-in functions before running it, but the researchers showed that some helper functions left within reach can be used to get back to everything Python can do.

An analogy: it is like a form with a "notes for the warehouse" box, where the warehouse robot reads the notes as instructions. Someone removed the most dangerous instructions from the robot's vocabulary, but left one that opens the door to the rest.

The result: whoever can send a filter to the dumper can run code on the machine that serves the model.

Are you affected? What to do now

You are only affected if all of these are true:

• You run SGLang yourself (self-hosted), on a version from 0.5.10 to 0.5.22. Version 0.5.22, released October 16, 2026, is the newest release and is still affected.
• The dumper's network interface is turned on, meaning the environment variable DUMPER_SERVER_PORT is set to a port number or to reuse. By default it is not set, and the dumper's HTTP server does not start.
• Someone untrusted can reach that interface over the network.

If you use a hosted AI API, or run SGLang without setting DUMPER_SERVER_PORT, there is nothing to do today.

Checklist for teams that run SGLang:

• Check the version. Run pip show sglang inside the environment or container that runs the server.
• Check the setting. Look for DUMPER_SERVER_PORT (and DUMPER_ENABLE) in your launch scripts, container definitions, Kubernetes manifests and .env files. On a running Linux host, the process environment (for example in /proc/<pid>/environ) shows what was actually set.
• Turn it off in production. Remove DUMPER_SERVER_PORT from any server that does not need live debugging, then restart. This is the only complete mitigation while no patch exists.
• If you need the dumper, fence it off. In the numeric-port mode, SGLang's code starts a separate HTTP server on all network interfaces with no authentication. Firewall that port so only the debugging workstation can reach it. In reuse mode, the routes sit on the main model API; the reporter says that, unless an admin key is configured, an ordinary API key is enough.
• Keep model servers off the internet. Put SGLang behind a gateway or reverse proxy with authentication, and restrict who can reach its ports.
• Look back. If the dumper was ever exposed, review access logs for requests to /dumper/ paths from unexpected addresses. Treat a server where you cannot rule this out as possibly compromised: rotate any secrets it holds (model-hub tokens, cloud credentials, API keys) and rebuild it from a clean image.
• Watch for a fix. Follow the SGLang GitHub issue below and upgrade once a release that addresses it is published.

No official indicators of compromise have been published, and there are no reports of exploitation in the wild. The CVE is not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of October 19, 2026.

The expert view

Root cause. This is a textbook eval injection (CWE-95). A debugging convenience accepts a user-supplied expression and evaluates it with Python's eval(), using an emptied built-ins namespace as a "sandbox". That pattern has a long history of failing: in Python, almost any function object gives a path, through its attributes, back to its module's globals and from there to the real built-ins. The reporter showed that the regular-expression helper functions placed in the namespace for convenience are enough to escape. Stripping built-ins limits typos, not attackers.

Attack chain, conceptually. The attacker reaches the dumper's control endpoint, sets a malicious filter through its configuration method, and waits. The filter is evaluated during the next forward pass of the model, inside the scheduler process, which has the server's full privileges, GPU access, and whatever credentials and model weights live on the host. No user interaction is needed.

Why the defenses failed. Two layers were missing. The standalone dumper server binds to all network interfaces with no authentication in the code; the reuse mode relies on SGLang's optional admin key. And the evaluator itself trusted its input. Debug interfaces that are "never meant for production" have a way of ending up in production containers, copied from a tuning run into a deployment manifest.

Severity in context. VulnCheck, the CVE assigner, rates it 9.2 (critical) under CVSS 4.0, with the vector noting "attack requirements present" (AT:P), which reflects the non-default configuration. Some CVE aggregators list a CVSS 3.1 score of 8.1; we could not find that score in a primary source. Both numbers describe the worst case. For the large majority of deployments, where the dumper is off, real-world risk is low. For an organization that enabled the standalone dumper on a reachable network, it is about as bad as it gets: unauthenticated code execution on a GPU server. We would call the score fair for exposed instances and overstated as a description of typical risk.

The broader trend. This is the latest in a run of AI-infrastructure flaws with the same shape: internal control or debug channels that assume a trusted network. Recent examples include the unauthenticated internal services in the LightLLM inference server, the Mooncake KV cache layer that sits under vLLM and SGLang, and the open-by-default control API in the Archon coding agent (CVE-2026-111322). Inference stacks are built by teams optimizing for throughput on private clusters, and their side channels are often never threat-modeled for the internet.

What is still unknown. There is no fixed version. On October 14, 2026, a community contributor opened a pull request (#44205) replacing eval() with a restricted parser, but a maintainer closed it the same day, unreviewed, as part of a sweep of near-duplicate pull requests from that account. When we checked on October 19, the issue was still open with no maintainer response. We do not know when an official fix will ship, whether it will remove the expression filter entirely, or how many internet-reachable SGLang servers have the dumper enabled. No exploitation has been reported.

Official sources

• VulnCheck advisory: SGLang 0.5.10 through 0.5.22 Code Injection via Debug Dumper Filter (CVE-2026-111391), published October 16, 2026
• SGLang GitHub: Issue #44188, "Dumper filter eval() enables scheduler-process RCE" (reporter's original write-up, October 14, 2026)
• SGLang source: dumper.py at v0.5.22
• SGLang GitHub: Pull request #44205 (community fix, closed unmerged)
• CVE record: CVE-2026-111391
• PyPI: sglang release history
• Coverage: CVE Brief, October 18, 2026