# The NEAR AI breach shows where confidential inference stops

NEAR AI says an attacker exploited an SGLang remote-code-execution flaw, reached data from 18 legacy agents and about 100 Private Chat users, and could observe requests on one inference server.[1]

NEAR AI says an attacker used a remote-code-execution vulnerability in SGLang on November 8, 2026. The attacker ran code on one inference server, reached a deprecated Private Chat system, accessed 18 agents on a legacy deployment and exposed two customer API keys stored in logs.[1]

The incident also reached requests processed in confidential mode on the affected server. A trusted execution environment can protect data from the host and operator, but it cannot protect a request from vulnerable inference software running inside the same environment.

NEAR AI says it fixed the flaw across its servers and contacted confirmed affected users. It did not publish the vulnerable SGLang versions, a CVE or a public upstream patch. Operators should avoid mapping this incident to a particular public SGLang advisory without evidence, and they should review network exposure, software versions, logs, secrets and lateral-movement paths now.[1][2]

## What NEAR AI confirmed

[NEAR AI's incident report [1]](https://near.ai/blog/security-incident-report-sglang-vulnerability) says an unauthorized party exploited a remote-code-execution flaw in SGLang and gained code execution on one inference server. From that server, the party reached other parts of NEAR AI's infrastructure.

NEAR AI says the party downloaded names and email addresses for about 100 users of its deprecated Private Chat product, plus plan and balance information for some accounts. The company found no indication that stored Private Chat conversations or uploaded files were accessed.[1]

The party also accessed 18 agents on a legacy NEAR AI Agents deployment outside the company's trusted execution environment. NEAR AI says the retrieved data included chat history, settings and logs. Two NEAR AI Cloud customer API keys appeared in those logs, and the company revoked them.[1]

## Why confidential mode did not contain the exposure

NEAR AI says the party could observe requests processed on the accessed server on November 8, including requests running in confidential mode. The company explains that confidential computing protects data from the infrastructure operator and host, but vulnerable software inside the environment can still read the data it is processing.[1]

An enclave changes which systems must be trusted. It does not remove the inference engine, model server, request parser or application code from the trusted computing base. If an attacker can run code beside the request inside that boundary, memory encryption against the host does not separate the attacker from the request.

Attestation can prove which measured software started. Teams still need a process for assessing that software, updating it and refusing workloads when an attested version is vulnerable. A valid measurement of unsafe code remains unsafe code.

## Do not assign the incident a CVE that NEAR AI did not name

NEAR AI says it reported the vulnerability to the SGLang project, but its public report does not name affected versions, a commit, a CVE or an upstream release containing the fix.[1] The Hacker News independently noted the same missing details.[2]

SGLang has other published remote-code-execution advisories. For example, CVE-2026-93034 concerns unsafe deserialization in a distributed-initialization path, while CVE-2026-111391 concerns a debug dumper filter in versions 0.5.10 through 0.5.22.[3][4] Neither advisory is confirmed as the flaw used against NEAR AI.

Operators should inventory every SGLang deployment and compare it with all applicable advisories, but they should keep the incident flaw labelled unknown until NEAR AI or SGLang publishes a reliable mapping. Guessing can send a response team toward one code path while another remains exposed.

## Response checklist for SGLang and private-inference operators

- Record every SGLang version, image digest, startup flag, exposed port and network path across development, evaluation and production.
- Ask the provider or platform owner for the exact fixed build. Do not treat a restart or a generic latest tag as evidence that the relevant flaw is gone.
- Remove public access to inference control, distributed-initialization, debug and worker ports. Put required routes behind authentication and a narrow allowlist.
- Rotate tokens found in prompts, traces, crash dumps and agent logs, then review their issuing systems for use after the earliest possible exposure.
- Separate inference workers from agent memory, account databases, old products and administrative networks with enforceable egress and service identities.
- Preserve server, identity, network and tool-call logs before redeployment, and search for process execution, unexpected downloads and lateral access.
- Re-run attestation and isolation tests against the fixed image, including a test that confirms one compromised worker cannot reach another service.

## A practical containment test

Create a staging worker with the same image, flags and network policy as production. Give it synthetic requests and canary credentials that have no real authority. From the worker process, test which files, metadata services, databases, agent stores and outbound hosts are reachable.

The expected result should be a short allowlist, rather than general access to the environment. Alert when the canary credential is read or used. Then repeat the test after every model-server, container, driver or orchestration change.

Pair that exercise with a request-privacy test. Confirm which components can see plaintext before, during and after inference, where traces go and how long every copy remains. Describe privacy using that observed path, rather than the presence of a TEE alone.

## What remains uncertain

The public report does not identify the exact SGLang flaw, vulnerable versions, entry point, attacker, dwell time before November 8 or a public upstream patch. It also does not say how the inference server reached the deprecated Private Chat system.[1]

NEAR AI says requests on the affected server could have been observed. It does not publish a count of those requests or say whether every person whose request passed through that server received a notice.[1][2]

The confirmed numbers describe what NEAR AI had established when it published the report. They do not prove that no additional data was accessed. Teams should watch the incident report and the SGLang advisory list for updates.

## Frequently asked questions

- Was every NEAR AI customer affected? NEAR AI says it contacted users whose account details or agents were confirmed as accessed. Its public report describes one accessed inference server.
- Did the attacker read stored Private Chat conversations? NEAR AI says it found no indication that stored conversations or uploaded files were accessed.
- Were confidential-mode requests protected? NEAR AI says requests processed on the accessed server could have been observed because the vulnerable SGLang software ran inside the protected environment.
- Which SGLang version fixes the incident flaw? The public report does not say. Ask for the exact fixed build and monitor SGLang's security notices.
- Should operators rotate every credential? Rotate credentials that appeared in affected prompts, agent histories, traces or logs, plus credentials available to the compromised worker. Use logs and scope to decide whether other credentials require replacement.
- Does a TEE still help? Yes. It can protect data from the host and operator, but operators must also secure and update every component that handles plaintext inside the environment.

## Sources

- [[1] NEAR AI: SGLang security incident report](https://near.ai/blog/security-incident-report-sglang-vulnerability)
- [[2] The Hacker News: SGLang exploit and NEAR AI impact](https://thehackernews.com/2026/11/sglang-rce-exploit-breaches-near-ai.html)
- [[3] GitHub Advisory Database: CVE-2026-93034](https://github.com/advisories/GHSA-w4hv-c72g-pqx6)
- [[4] GitHub Advisory Database: CVE-2026-111391](https://github.com/advisories/GHSA-vfgj-p7f7-r3v8)
- [[5] SGLang security advisories](https://github.com/sgl-project/sglang/security/advisories)