NEAR AI Says SGLang RCE May Have Exposed Confidential Requests

If you run SGLang or buy "confidential inference" from a provider that does, NEAR AI's breach is your incident too: the enclave did its job, and the engine inside it let the attacker in anyway. On November 9, NEAR AI disclosed that an attacker used a remote code execution flaw in SGLang to run code on one of its inference servers, could have observed requests processed there on November 8 (confidential-mode requests included), and then moved into older systems that held user data, agent histories and two customers' API keys.

The fix for your own stack is mostly configuration, and CERT/CC published it in July. SGLang's upstream maintainers had not shipped patches for the six flaws in CERT/CC's July 30 note, and one setting that note flags, SGLANG_USE_PICKLE_IPC, still defaulted to true when it was published.

---

What NEAR AI Says the Attacker Reached

The attacker started on one inference server and ended up in systems that were never inside the enclave. According to NEAR AI's incident report, the sequence was:

1. Code execution on one inference server through an SGLang remote code execution vulnerability.
2. Visibility into user requests processed on that server on November 8, "including requests in confidential mode."
3. A pivot to an internal system behind Private Chat, a service NEAR AI had already deprecated, which exposed names and email addresses for about 100 users, plus plan and balance details for some.
4. Access to 18 agents on a legacy NEAR AI Agents deployment that did not run in the confidential computing environment: their chat history, settings and logs.
5. API keys for two NEAR AI Cloud customers, which had been written to logs.

NEAR AI says it found no sign that stored Private Chat conversations or uploaded files were accessed. It revoked sessions, administrative credentials and the two exposed keys, replaced every agent token, took Private Chat offline, deployed a fix to all inference servers and reported the flaw to the SGLang project. Decrypt notes the company did not say whether the stolen keys were used.

The report leaves out the details you need to judge your own exposure. The Cloud Security Alliance's research note points out that NEAR AI has not named the exploited CVE or SGLang version, the detection date, or how long the attacker was inside. Until it does, you cannot tell whether the bug that hit NEAR AI is one of the publicly listed SGLang flaws or a new one, so treat every listed flaw as live.

Why a TEE Did Not Stop It

A trusted execution environment protects your data from the host and the operator. It does nothing about the software you put inside it. NEAR AI says so directly: confidential computing "does not protect against a vulnerability in the software running inside the environment" (Decrypt, quoting the report).

A trusted execution environment (TEE) is a hardware-isolated region of memory, such as Intel TDX on the CPU or confidential-computing mode on an Nvidia GPU, that the host operating system and the cloud operator cannot read. Remote attestation is the signed proof of which code is running inside it. Neither proves that code is safe. An inference engine has to decrypt a prompt to run the model on it, so anyone with code execution inside the engine sees the plaintext, and to the hardware that looks like normal processing.

The CSA note puts the attestation problem plainly: a vulnerable build that is part of the measured image attests correctly, because attestation confirms which code is running and says nothing about whether that code is safe. It recommends that relying parties deny-list attestation measurements tied to known-vulnerable versions and that providers publish component version manifests.

That is a procurement question for anyone buying confidential inference. Brave's October 15 post on end-to-end encrypted Leo chat describes the model running "inside a sealed, Nvidia-backed hardware enclave, operated by NEAR AI," on Intel TDX with Nvidia confidential GPUs, with Brave's own oracle verifying each deployment's attestation. The same post says the third-party model runtime is not rebuilt from source and is pinned by a hardware-attested deployment log. Brave does not name the runtime, and NEAR AI's report does not identify Brave users among those affected. A buyer's verification that thorough still confirms only the enclave, the hardware and the model. The engine's patch level stays the provider's business unless the contract makes it yours.

If you evaluated providers against our confidential GPU inference buyer's guide, add a row: which serving engine, which version, and what happens to attestation when that version gets a critical CVE.

---

How Many Unpatched SGLang Flaws Are Public?

At least fourteen, across five CERT/CC notes in 2026, and none of the five recorded a vendor patch at publication.

CERT/CC note	Published	Flaws	What it says about the fix
VU#665416	March 12	CVE-2026-3059, CVE-2026-3060, CVE-2026-3989: pickle.loads() on untrusted data in the multimodal generation and encoder disaggregation modules and replay_request_dump.py	A proposed patch was submitted, but no maintainer response at publication
VU#915947	April 20	CVE-2026-5760: a malicious GGUF model's chat template runs code via /v1/rerank	"No response or patch was obtained during the coordination process"
VU#777338	May 18	CVE-2026-7301 (pickle.loads() on the multimodal generation scheduler socket that binds to 0.0.0.0 by default), CVE-2026-7302 (path traversal), CVE-2026-7304 (dill.loads() RCE)	Vendor notified April 2; no patch, no statement
VU#326070	July 16	CVE-2026-14890: the expert-parallel backup subsystem's ZeroMQ socket unpickles payloads from the network without authentication (feature must be enabled)	No patch; maintainers did not respond
VU#281278	July 30	Six CVEs, CVE-2026-15969 to CVE-2026-15978, including unauthenticated RCE in /load_lora_adapter_from_tensors and credential leakage from /server_info	"No patches are available from the project maintainers"

The Hacker News reported a CVSS score of 9.8 for CVE-2026-5760 and counted 26,100 GitHub stars on the project, which gives a rough sense of how widely SGLang is deployed.

The July note is the one to work from, because its six flaws sit on endpoints a typical deployment leaves on. CVE-2026-15976 turns /update_weights_from_disk into pickle deserialization through a torch.load(..., weights_only=False) fallback. CVE-2026-15977 makes /server_info return API keys and SSL keyfile information when only --admin-api-key is set. CVE-2026-15978 lets an attacker pull model weights over NCCL when no API keys are configured. CVE-2026-15974 is SSRF and local file read through the image_url field in /v1/chat/completions. CERT/CC adds that the maintainers are refactoring toward msgpack to remove pickle from IPC.

Upstream may have shipped fixes since those notes went out. Third-party vulnerability trackers report that v0.5.10 fixed the March pickle flaws, but no fixed release for anything in the April, May or July notes could be confirmed for this article. NEAR AI says it deployed a fix on its own servers, but it did not say what it changed. Check the SGLang repository's security advisories yourself before you assume an upgrade closes anything.

The Industry Has Hit This Bug Class Before

Pickle over a network socket is a known pattern, and SGLang has carried it before. In November 2025, Oligo Security's research on what it called ShadowMQ found the same unsafe ZeroMQ-plus-pickle code copied across inference frameworks: Meta's Llama stack, NVIDIA TensorRT-LLM, vLLM, Microsoft Sarathi-Serve, Modular Max Server and SGLang. TensorRT-LLM was fixed in 0.18.2. SGLang's fixes were listed as incomplete, and the vulnerable SGLang file was adapted from vLLM.

The lesson from that round still applies. Serving engines share code, so a deserialization bug in one shows up in its forks and neighbours, and the fix lands at different speeds in each. It is also why the October vLLM advisories we covered in vLLM 0.30.0 Can Run Code Through Ghostscript Images belong on the same risk register as this one. Cloudflare's GLM-5.3 KV-cache leak, which we covered on October 29, also ran on SGLang, and the Fireworks breach disclosed the same week as NEAR AI's put stored customer secrets at risk at another inference provider.

When we compared runtimes in vLLM vs TensorRT-LLM vs SGLang, the decision rested on throughput and features. Maintainer response time on security reports belongs in that decision now. Five CERT/CC notes between March and July, none with a vendor patch at publication, is a data point you can put in front of an architecture review.

---

What to Do About SGLang This Week

Every item below comes from CERT/CC's published mitigations or the CSA note, and each can be done without waiting for an upstream patch.

This Week:

1. Inventory every SGLang process. Include notebooks, eval clusters and the "temporary" box someone stood up for a LoRA test. Record the version and which ports listen on which interfaces. The CSA note recommends checking each against VU#915947, VU#777338 and VU#281278; add VU#665416 and VU#326070 to that list.
2. Set SGLANG_USE_PICKLE_IPC=false on every deployment, as CERT/CC recommends, and test that serving still works. Do not treat the flag as sufficient on its own: CVE-2026-93034, disclosed in October, is reported to keep pickle deserialization reachable through the msgpack path when data-parallel attention runs with a non-loopback --dist-init-addr, so bind that address to loopback too.
3. Turn off what you do not use. If you do not hot-swap adapters or weights, block /load_lora_adapter_from_tensors and /update_weights_from_disk at the proxy. Block /server_info from anything but an admin network. Never run SGLang without API keys.
4. Move the scheduler, broker and admin interfaces off untrusted networks. The multimodal generation scheduler socket in CVE-2026-7301 binds to 0.0.0.0 by default; bind it to loopback or a private segment.
5. If you are a NEAR AI Cloud customer, rotate your API keys even if you did not get a notice, and treat unsolicited messages that cite your account or balance with caution, as NEAR AI advises.

This Month:

1. Grep your inference logs for keys and tokens. Two of NEAR AI's losses were API keys sitting in logs. Redact credentials and prompts before logs leave the host, then rotate anything you find.
2. Lock down egress from inference hosts and run the engine with least privilege: read-only filesystem, a seccomp profile, no shell or package manager in the production image. The CSA note lists all of these.
3. Shut down legacy deployments completely. NEAR AI's 18 exposed agents lived on a deployment outside the enclave, and its user data sat behind a deprecated service. Deprecated services keep their credentials and network paths until someone removes them.

Before Your Next Inference Renewal:

1. Ask every inference provider four questions in writing: which serving engine, which version, how fast they patch a critical CVE in it, and whether their attestation policy rejects builds with known critical flaws.
2. Ask for a component version manifest with each attested deployment, so you can check the engine version yourself instead of trusting a marketing claim of "confidential."

The Bottom Line

Confidential computing for AI is repeating an old pattern from web security, where strong transport encryption sat in front of application code that attackers simply exploited. The enclave protects you from the operator. The engine inside it is ordinary open-source code with at least fourteen publicly listed flaws that had no upstream patch when CERT/CC published them, and it needs the same patching, segmentation and log hygiene as any other internet-facing service.

Set SGLANG_USE_PICKLE_IPC=false and block /server_info before you read the next vendor's attestation report.

Continue Reading

• Cloudflare GLM-5.3 Leaked Customer Data in 155 Responses
• Rotate Every Secret You Stored on Fireworks After Breach
• Azure, Google and AWS Compared for Confidential GPU Inference
• vLLM 0.30.0 Can Run Code Through Ghostscript Images
• vLLM vs TensorRT-LLM vs SGLang: Default to vLLM
• Test Your PyTorch Workloads on Ironwood Before Choosing TPU 8tx