Source: CERT/CC Vulnerability Note VU#777338 — https://kb.cert.org/vuls/id/777338
SGLang has three serious bugs, and no patch is available yet#
CERT/CC says SGLang contains three vulnerabilities: two remote code execution paths and one path traversal issue. The practical condition matters. According to the note, exploitation requires multimodal generation mode to be enabled and the attacker to have network access to the SGLang service.
That still leaves a large risk window for teams running SGLang as part of AI infrastructure. SGLang is an open-source framework for serving LLMs and multimodal models. CERT/CC notes support for models such as Qwen, DeepSeek, Mistral, and Skywork, plus OpenAI API compatibility. In other words, this is not a niche desktop tool. It sits in the request path for model-serving stacks.
The sharper part of the advisory is not only the impact. It is the coordination status. CERT/CC says no patch is available at the time of publication, and that it did not receive a response from the project maintainers during coordination.
That changes how operators should read the note. This is not a normal “upgrade to fixed version” advisory. For now, the mitigation is exposure control.
What CERT/CC says is vulnerable#
CERT/CC describes three separate issues in SGLang’s multimodal generation runtime.
The first is a remote code execution issue in the multimodal generation runtime scheduler’s ROUTER socket. The note says the socket contains a sink that calls on incoming messages, enabling RCE when exposed to the internet.
CERT/CC distinguishes this issue from CVE-2026-3060 and CVE-2026-3059. Those earlier issues involved the ZMQ broker automatically binding to all network interfaces without user awareness. The new issue, tracked as CVE-2026-7301 in the advisory text, is described as exposed to the internet by default through the scheduler host, which binds to 0.0.0.0 by default.
That binding detail is important. A service bound to 0.0.0.0 is reachable on all network interfaces unless the host firewall, cloud security group, container network policy, or upstream proxy blocks it. In AI infrastructure, it is common for internal tooling to get deployed quickly behind assumed-private networks. Those assumptions fail when the service lands in a permissive VPC, a shared Kubernetes namespace, a misconfigured ingress path, or a development box with public reachability.
The second issue is an unauthenticated path traversal vulnerability in the multimodal generation runtime. CERT/CC says an attacker can write arbitrary files anywhere the server process has write access by including path traversal sequences in the upload filename sent to specific endpoints.
This is not automatically the same as code execution, but it is still serious. Arbitrary file write can become credential theft, configuration tampering, persistence, or a staging step for later execution depending on where the process can write and how the host is configured. The advisory does not claim every deployment is equally exploitable beyond file write, so operators should avoid overextending the finding. The safe assumption is narrower and still bad: if an untrusted user can reach the vulnerable endpoint, they may be able to place files where the SGLang process can write.
The third issue is another unauthenticated remote code execution path when the --enable-custom-logit-processor option is enabled. CERT/CC says Python objects loaded through this path are deserialized without validation.
That condition is worth checking directly. If the option is not enabled, this specific RCE path may not apply as described. If it is enabled on a network-reachable service, the risk is much higher because unsafe deserialization is a well-known execution primitive, especially in Python systems that accept attacker-controlled serialized objects.
The highest-risk deployments are exposed services#
The advisory’s core risk model is simple: multimodal mode plus network access. Public internet exposure is the obvious danger, but it is not the only one.
Many model-serving systems are treated as internal services and then wired into notebooks, API gateways, batch workers, evaluation harnesses, agent frameworks, or customer-facing applications. If SGLang is reachable from any untrusted tenant, user-controlled workload, compromised container, or loosely governed internal network, the same class of risk applies.
The phrase “network access” should not be read too narrowly. It includes direct access to the SGLang service, reachable scheduler interfaces, exposed container ports, cloud load balancers, permissive firewall rules, and any proxy path that forwards attacker-controlled requests to the affected endpoints.
The project’s OpenAI API compatibility also matters operationally. Compatibility encourages drop-in deployment. Teams can swap model-serving backends without fully revisiting the trust model around every backend-specific interface. That is efficient when the software is mature and tightly scoped. It is dangerous when auxiliary runtime surfaces bind broadly or accept complex inputs such as uploads and serialized Python objects.
What to check now#
Until a patch exists, CERT/CC recommends restricting access to service interfaces, keeping them away from untrusted networks, and using network segmentation and access controls to block unauthorized interaction with vulnerable endpoints.
For operators, that translates into a short checklist:
- Confirm whether SGLang is deployed anywhere in your environment, including labs, evaluation clusters, notebooks, and temporary GPU hosts.
- Check whether multimodal generation mode is enabled.
- Check whether the scheduler host or related interfaces bind to
0.0.0.0. - Verify that exposed ports are blocked from the public internet and from untrusted internal networks.
- Review Kubernetes Services, ingress rules, security groups, host firewalls, VPN routes, and container port mappings.
- Check whether
--enable-custom-logit-processoris enabled. - Treat upload-capable endpoints as sensitive until there is a fix or a clear compensating control.
- Run the service with the least filesystem privilege possible, so any file-write bug has less room to damage the host.
If the service must stay online, put hard access control in front of it. Do not rely on obscurity, undocumented endpoints, or the assumption that only trusted clients know the port. If a reverse proxy is used, verify what it actually forwards. If the service is meant to be internal, make that true at the network layer.
What not to overclaim#
The CERT/CC note does not say there is active exploitation in the wild. It also does not provide a patched version, a maintainer statement, or a complete deployment matrix. The absence of those details should not be turned into certainty in either direction.
It would be wrong to say every SGLang installation is remotely exploitable by default. CERT/CC gives conditions: multimodal generation mode must be enabled, and the attacker must have network access to the service. One RCE path also depends on --enable-custom-logit-processor being enabled.
It would also be weak to dismiss the issue because of those conditions. AI serving stacks often live in fast-moving environments where experimental features, broad binds, and internal-only assumptions are common. A serious vulnerability behind a “must have network access” condition is still serious when the service was never meant to be hardened as an internet-facing surface.
Bottom line#
There is no patch to install yet. The useful move is to reduce reachability.
If SGLang is running with multimodal generation enabled, treat it as a sensitive service boundary. Remove public exposure, restrict internal access, check the custom logit processor option, and limit filesystem permissions. The difference between a contained bug and host compromise may be a single open interface.