An RCE in SGLang opened NEAR AI's inference server to an attacker: ~100 users' data, 18 agents, and 2 API keys. Incident breakdown and defense.
On Sunday, November 8, 2026, an attacker exploited a remote code execution (RCE) vulnerability in SGLang — a popular open-source inference engine for large language models — and gained code execution on one of NEAR AI's inference servers. This isn't a theoretical threat or a lab PoC: the attacker genuinely moved from one breached server to internal systems, stole credentials for about a hundred users, and reached the data of 18 AI agents.
The incident is valuable not for its scale — comparatively few people were affected — but for the lesson it gives the whole industry: "confidential computing" in a Trusted Execution Environment (TEE) doesn't protect against a vulnerability in the software running inside that environment. Let's break down what happened, why it was possible, and how to protect your own systems.
What happened
NEAR AI is a division of the NEAR Protocol ecosystem that develops infrastructure for working with AI agents and provides the NEAR AI Cloud inference service. In its official incident report, published November 9, the company said an unauthorized party used an RCE vulnerability in SGLang — the open-source inference engine running on its servers — and executed code on one inference server.
Then, per the investigation, the attacker moved from the breached server into other parts of the infrastructure. The first destination was an internal system behind an already decommissioned Private Chat product — a legacy app the company had long stopped supporting but which remained connected to the internal network. That's exactly where the attacker downloaded user credentials from.
A separate alarming point: the attacker could see requests processed on the compromised server on November 8 — including requests sent in confidential mode, i.e., a mode meant to guarantee privacy even from the company itself.
How the attack worked: from RCE to agent data
The keyword in the whole incident is RCE in SGLang. SGLang is a server framework that runs LLM and multimodal models (Qwen, DeepSeek, Mistral, Skywork, and others) and generates responses to requests. It deploys as a separate service and typically listens on network ports, processing inference requests.
The vulnerability let the attacker execute arbitrary code on the server running SGLang. Having gained code execution on one node, the attacker got a foothold and began lateral movement — toward internal systems reachable from that node but not meant for external access.
That's how he reached:
- The internal system behind Private Chat — decommissioned but not fully disconnected. User accounts were exfiltrated from there.
- 18 AI agents on a legacy NEAR AI Agents deployment that did not run in a TEE. Chat history, settings, and logs were extracted from these agents.
- Logs exposing the API keys of two NEAR AI Cloud customers.
This chain illustrates a classic infrastructure-security problem: one vulnerable piece of network-exposed software becomes a gateway to everything connected to it. Even if other systems are themselves protected, trust between internal services makes them reachable to anyone already inside.
Separately, note that the targets were specifically AI agents. An agent by definition accumulates a lot of context — conversation history, tool access, sometimes credentials and keys. That makes it far more valuable loot than an ordinary web account: one compromised agent can reveal not one fact but a user's or team's whole working context. The trend we've seen in recent months: attacks increasingly target AI infrastructure and agents, not just classic web apps.
What exactly was stolen
NEAR AI has so far confirmed the following leak scope:
- Credentials of ~100 users — email addresses, names, and for some accounts also plan details and account balance.
- Data of 18 AI agents — chat history, settings, and logs from a legacy deployment that didn't use TEE.
- Two NEAR AI Cloud API keys — exposed in logs; both already revoked. The company didn't say whether the attacker managed to use them.
Important: per the investigation, there are no signs that stored Private Chat conversations or uploaded files were accessible. At the same time, the company explicitly acknowledges that requests processed on the compromised server on November 8 — including confidential ones — could have been visible to the attacker. This isn't a confirmed content leak but a real possibility that can't be ruled out.
NEAR Protocol and other NEAR services, per the company, were not affected.
Why confidential computing didn't help
This is the incident's most important lesson. NEAR AI positions its Cloud as a "confidential inference" service: requests are processed inside a Trusted Execution Environment (TEE) — a hardware-isolated enclave meant to protect data from the operator and host. The idea is that even the company owning the servers can't see request content.
But a TEE only protects against an external observer. It doesn't cancel vulnerabilities in the software running inside the enclave. And SGLang is exactly such software: it runs in the protected environment, and a vulnerability in it let the attacker execute code inside that very enclave. As the company itself put it: "Confidential computing protects data from the operator and host. It does not protect against a vulnerability in the software running inside the environment — and that's exactly what happened here."
In other words, a trusted environment isn't a magic shield but one layer of defense. If the code you run inside the enclave has RCE, the enclave protects no more than a locked door whose key lies under the doormat.
SGLang: vulnerabilities were known before
For anyone tracking AI-infrastructure security, this incident shouldn't come as a surprise. SGLang has had serious issues before.
- CVE-2026-3059 — unauthenticated RCE via the ZMQ broker: the multimodal-generation module deserialized untrusted data with
pickle.loads()without authentication. CISA-ADP rated it CVSS 9.8 (Critical). - CVE-2026-3060 — another unauthenticated vulnerability, this time in the disaggregation module.
Even more telling is July's CERT/CC report (VU#281278), which described six vulnerabilities in SGLang at once: RCE, server-side request forgery (SSRF), local file reads, credential leaks, and model-weight theft. Most required no authentication — just network access without API keys or accounts. At publication, no vendor patches existed, and coordination with the project, per CERT/CC, was "unsuccessful."
This backstory matters: it shows the problem isn't one "accidental" vulnerability but a systemic state of security in a framework increasingly used in production.
How NEAR AI responded, and the patch status
The company's response was fast and, it appears, competent. On the evening of November 9 (around 23:14 UTC), NEAR AI paused NEAR AI Cloud inference as a precaution and published the incident report the same day. The service was restored about four hours later, after remediation.
What was done:
- revoked all active sessions and admin credentials;
- replaced all agent tokens;
- took Private Chat offline;
- deployed the SGLang vulnerability fix on all inference servers;
- completed rotation of remaining credentials and a full forensic review.
The company notified users whose data or agents were confirmed compromised (emails come from security@near.ai), separately contacted the owners of all 18 agents, and promised necessary regulatory notifications.
But there's an important nuance for anyone who themselves runs SGLang: there's currently no public patch. NEAR AI reported the vulnerability to the SGLang developers, but as of November 10 no CVE has been assigned, no technical details or vulnerable-version list published, and the project's latest release — v0.5.23 from November 2 — predates the incident. That means other SGLang operators currently have no applicable fix.
What SGLang operators and users should do
While no official patch exists, defense rests on exposure limitation and network hygiene. For teams deploying SGLang or similar inference engines:
- Don't expose inference servers to the public internet. SGLang and its internal ports aren't meant for direct external access. Put them behind VPN, firewall, or an internal network with strict access control.
- Limit each node's network reach. An inference server shouldn't reach everything on the internal network. Segment the network and apply least privilege to inbound and outbound connections.
- Track the project's security releases. Subscribe to the SGLang project's GitHub advisories and react to new releases the moment a fix ships.
- Don't rely on TEE as the only defense. If you run a trusted environment, treat all code running inside the enclave with the same security-analysis rigor as the enclave itself — the very approach NEAR AI now says it's applying.
- Monitor the external perimeter. If you have legacy or decommissioned services, fully disconnect them from the network — it was precisely the "forgotten" Private Chat through which the attacker reached user data.
For affected NEAR AI users, the main advice is phishing caution. Since names, emails, and balance details were stolen, attackers can send convincing messages referencing your account or balance. Be suspicious of any unexpected message referencing your NEAR AI account, and don't follow links in such emails.
If you're unsure whether your credentials have already "roamed" the web, check your email via our breach-check tool — a quick way to assess whether your data appeared in known incidents.
Conclusion
The NEAR AI incident isn't the year's biggest leak, but it's one of the most instructive for an era when AI infrastructure becomes critical. It shows three things. First, inference software is now a full attack surface: frameworks like SGLang handle sensitive data and need the same security treatment as web servers or databases. Second, a trusted execution environment isn't a panacea — a vulnerability in the code inside the enclave nullifies its protection. And third, legacy but not-disconnected services remain the weakest link through which one vulnerability turns into a full leak.
While no public SGLang patch exists, the most reliable defense is to keep inference servers off the internet, segment the network, and closely track security updates. This is a case where infrastructure hygiene matters more than any single patch.
