AI Security

NEAR AI breached via SGLang flaw that bypassed its confidential AI

An SGLang code execution bug let an attacker into NEAR AI, exposing user data and agent logs despite its confidential computing enclaves.

Illustration of an AI chip inside a secure enclave with a warning signal, representing the NEAR AI breach

NEAR AI says an attacker abused a code execution bug in SGLang, a popular open-source model-serving engine, to break into its platform, take user account details and read legacy AI agents’ chat histories. The company admits its confidential computing enclave offered no protection against a bug in the software running inside it.

What happened

NEAR AI, which sells private and confidential inference through NEAR AI Cloud, published a security incident report on 9 November 2026. According to the company, an intruder used an SGLang bug allowing remote code execution, SGLang being the open-source engine NEAR AI relies on to serve large language models. The flaw let them run commands on a single inference host, which became a stepping stone into the wider infrastructure.

The company’s investigation found that the intruder reached an internal system sitting behind Private Chat, a feature NEAR AI had already deprecated, and downloaded account details for roughly 100 users. Those details were names and email addresses and, for some accounts, subscription plan and balance information. The attacker also reached 18 agents running on an older NEAR AI Agents platform, retrieving their chat histories, settings and logs. Those logs contained NEAR AI Cloud API keys belonging to two customers, which have since been revoked.

The most uncomfortable admission concerns live traffic. NEAR AI says that on 8 November the intruder may have been able to watch live user traffic handled by the breached host, confidential-mode traffic included. It found no sign that anyone touched stored Private Chat conversations or uploaded files.

In response the company killed every live session, revoked admin credentials, replaced every agent token, took Private Chat offline, deployed a fix for the SGLang flaw across all inference servers, rotated remaining credentials and completed a forensic review. Its report says NEAR AI Cloud is available again. NEAR AI says affected users and the 18 agent owners have been contacted directly.

The technical picture

NEAR AI has not published a CVE identifier, the affected SGLang version or any detail of the bug, saying only that it has reported the issue to the SGLang project. Whether it was a zero-day or a known, unpatched bug is unclear, which matters for other operators.

What is clear is the shape of the attack. An inference server is a network-facing service that accepts untrusted input, parses model files and request payloads, and often runs with access to GPUs, model weights, logs and orchestration credentials. A single code execution bug in that layer gave the attacker a launch point, and the onward movement into a deprecated chat backend and a legacy agent platform suggests the inference host could reach systems it had no business talking to.

The confidential computing angle is the real lesson. NEAR AI markets inference inside trusted execution environments (TEEs), hardware-isolated enclaves designed so that the cloud operator and host cannot see the data being processed. The company is candid that this model has a boundary: a TEE protects data from the people running the hardware, but it “does not protect against a vulnerability in the software running inside the environment”, in NEAR AI’s words. If the inference engine inside the enclave is compromised, the attacker is effectively inside the trusted boundary, with the same view of prompts and responses as the legitimate code.

The 18 agents that leaked data were not in the TEE at all: they ran on an older deployment, a reminder that legacy services outlive the hardened flagship.

Flow diagram showing the NEAR AI intrusion from SGLang exploitation through data access to containment

Why it matters for UK organisations

Many UK businesses now buy AI on the strength of privacy promises. Confidential inference and “we cannot see your prompts” claims are used to justify sending client documents, source code and personal data to third-party models. This incident shows those promises cover one threat (a curious or compelled operator) and not another (a bug in the stack).

There is a UK GDPR dimension too. Personal data in prompts processed by a compromised server is personal data potentially exposed, regardless of the enclave around it. Contracts with AI processors should require prompt breach notification, and a controller that receives such a notice may need to assess whether it must report to the ICO within 72 hours.

Finally, many UK teams self-host open models on engines such as SGLang, often on GPU instances spun up quickly by data science groups outside normal change control. Those servers are often over-exposed and under-patched.

Expert view

In my experience, AI serving infrastructure is treated as research kit rather than production software, and it shows. When we assess these environments we routinely find inference endpoints reachable from far more of the network than necessary, model servers running with broad cloud credentials, and logs that quietly capture API keys and prompt content.

Confidential computing is valuable technology, but it is an answer to a specific question: can the host see my data? It says nothing about whether the application inside the enclave is secure. Attestation proves which build is running, not that the build is free of bugs. Buyers should hear “confidential” as one control among many, not as a substitute for patching, segmentation and secrets hygiene.

Credit where it is due: NEAR AI disclosed quickly, named the root cause, admitted the limits of its own flagship feature and committed to apply the same scrutiny to the software around the enclave as to the enclave itself. The missing piece is technical detail on the SGLang flaw, which other operators need to judge their own exposure.

What to do now

  1. Inventory your inference engines. Find every SGLang, vLLM or similar serving instance, including those run by research or data teams, and update SGLang to the latest release. Watch the SGLang project for an advisory linked to this incident (Cyber Essentials: security update management).
  2. Restrict network exposure. Inference APIs should not be reachable from the internet or from broad internal ranges. Put them behind authenticated gateways and deny outbound access by default (Cyber Essentials: firewalls).
  3. Segment inference hosts. A compromised model server should not be able to reach chat backends, agent platforms or admin systems. Treat it as an untrusted workload (Cyber Essentials: secure configuration).
  4. Clean up logs and secrets. Stop logging API keys, tokens and full prompts; store credentials in a secrets manager and scope them tightly (Cyber Essentials: user access control).
  5. Retire legacy AI services. Decommission old agent deployments and deprecated features rather than leaving them running beside the hardened product.
  6. Question your providers. Ask AI vendors which components sit inside the confidential boundary, how they patch the serving stack, and how quickly they will notify you of an incident. If you use NEAR AI, check for a notice from the company and rotate any NEAR AI Cloud keys as a precaution.

Bottom line

NEAR AI’s breach is modest in scale, about 100 accounts, 18 agents and two API keys, but it punctures a growing assumption that confidential computing makes hosted AI safe by default. The enclave held; the software inside it did not. For UK organisations, the takeaway is to treat AI inference engines as exposed, high-value applications that need patching, segmentation and monitoring, and to read vendors’ privacy claims for what they actually cover.

Sources

Related Posts