SGLang's six CVEs (VU#281278): pickle RCE, leaked admin keys, no patch

On 30 July 2026, CERT/CC published vulnerability note VU#281278: six vulnerabilities in SGLang, the open-source LLM serving framework. They include unauthenticated remote code execution, server-side request forgery, credential leakage and model weight exfiltration. The researcher, Apoorv Dayal, published a companion write-up the same day. The CERT/CC note lists the vendor status as unknown for all six and says no patch was available at publication, because coordination attempts were unsuccessful.

If you serve models with SGLang, this is a mitigation exercise, not an upgrade.

What's affected

SGLang, with several findings tested on version 0.5.10.post1. CERT/CC does not list affected version ranges. The six CVEs:

CVE-2026-15976 is the most instructive. SGLang first loads checkpoints with weights_only=True. If that raises a RuntimeError mentioning a legacy tar format, it retries with weights_only=False. A file the restricted loader rejects is then loaded with full pickle behavior, which allows code execution before the model is validated. NVD scores it 9.8 and classifies it as CWE-502, deserialization of untrusted data.

Dayal's write-up says a local legacy checkpoint delivered through the HTTP model path executed a test payload. It also says a non-local model_path can reach the Hugging Face download path, and that a repository holding only .bin files selects the unsafe loader. A full chain from a malicious hub repository to code execution was not run end to end.

For CVE-2026-15977, /server_info serialized the full configuration, including api_key, admin_api_key and ssl_keyfile_password, without an authentication decorator.

How to check if you're exposed

Find SGLang processes and how they are bound:

ps aux | grep -i "sglang" | grep -v grep
ss -ltnp | grep -E "30000|sglang"
pip show sglang | grep -i '^version'

Check whether the sensitive routes answer from a host that should not reach them:

curl -s -o /dev/null -w '%{http_code}\n' http://<your-host>:30000/server_info

A 200 from outside the management network means the admin key may already be exposed. Check the environment for the risky settings:

env | grep -E "DUMPER_SERVER_PORT|SGLANG_USE_PICKLE_IPC"

Finally, list the model files your servers load. Anything in .bin, .pt or tar formats from a source you do not control is a candidate for the unsafe loader.

What to do now

1. Bind SGLang to loopback or a private network, and enforce route-level policy at a reverse proxy.
2. Rotate API and admin keys if /server_info was reachable without proper authentication.
3. Disable the dumper, remote model updates, LoRA tensor loading and distributed weight routes when you do not use them.
4. Set SGLANG_USE_PICKLE_IPC to false where your setup is compatible. CERT/CC notes it defaults to true.
5. Restrict outbound access from inference workers, which limits SSRF and weight exfiltration.
6. Prefer safetensors for models, and reject untrusted .pt and .bin checkpoints and legacy tar formats.

How this could have been avoided

• Never retry a failed safe load with an unsafe one. The fallback turned a rejection into the vulnerability. A loader that refuses should stay refused.
• Use formats that cannot execute code. safetensors stores tensors without arbitrary object reconstruction, so a hostile checkpoint cannot carry a payload.
• Separate the management plane from inference. Weight updates, server info and the dumper do not belong on the port that serves user requests.
• Fail closed on admin authentication. Several findings depended on no key being set or only one key being set. A server that refuses to start without credentials removes those states.
• Replace denylists with allowlists. The SafeUnpickler bypass shows the limit of blocking known bad names. Dayal's write-up calls a denylist-only approach insufficient.

Why it matters

Serving frameworks sit at an odd point. They are infrastructure, so teams give them the access of infrastructure: GPUs, model storage, cloud credentials. They are also young, so their input handling has not been tested the way a web server's has.

The CERT/CC outcome is the harder lesson. With the vendor status unknown and no fix, the usual ritual of "find the fixed version, schedule the upgrade" does not apply. What replaces it is knowing where SGLang runs, which routes are reachable, and which keys it holds. That is inventory work, and teams that did it before the advisory had an easy day.

Try it yourself

Take one model server in your stack and answer four questions: what port serves users, what port serves management routes, which model file formats it will load, and what happens if no API key is set. Then try the model risk scan below, which shows how model artifacts can be assessed before they are loaded.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CERT/CC: VU#281278, SGLang contains six different vulnerabilities
• Apoorv Dayal: SGLang disclosures
• NVD: CVE-2026-15976