A remote code execution flaw in SGLang, the open-source large-language-model inference engine, gave an attacker a foothold on one of NEAR AI's inference servers last Sunday — and, critically, visibility into requests that users believed were being handled inside a trusted execution environment (TEE). The company said 18 agents and roughly 100 users were affected, according to The Hacker News.
The incident, disclosed by NEAR AI earlier this week and reported by The Hacker News, is a useful case study in what confidential computing does and does not protect. Requests submitted through NEAR AI's "confidential mode" are processed inside a TEE, a hardware-isolated enclave designed to keep data opaque even to the host operator. But the attacker never needed to break the enclave. By exploiting SGLang to execute code on the underlying server, they could "have seen" requests being processed on that machine that day, including those routed through confidential mode — phrasing that reads as deliberately conservative disclosure, implying the enclave's internals were not themselves defeated.
That distinction is the story. A TEE attests to what happens inside its boundary: memory is encrypted, attestation reports verify the measured code, and keys are released only to code bearing a good quote. Everything crossing that boundary — requests arriving before entry, responses leaving after exit, and the host-side attestation and key-handling machinery itself — runs on infrastructure whose integrity must be assumed. A host-level code-execution foothold sits squarely on those boundaries. Confidential computing narrows the trust surface; it does not eliminate the need for host integrity.
The incident figures give the abstraction concrete weight: 18 agents, about 100 users, one compromised inference server, and a window of visibility limited to that day's traffic on that machine. For teams running self-hosted open-source inference stacks, the incident is less an argument against open source than an argument about how seriously serving engines and orchestration layers are treated in the patch cycle. SGLang-class components are often deployed as plumbing — pulled in as a dependency, rarely reviewed, and updated far less frequently than the models they serve — yet they process every request in cleartext before and after any enclave boundary.
Three practical takeaways for infrastructure teams:
Treat inference engines as first-class security dependencies. SGLang, vLLM, and comparable runtimes warrant the same monitoring, advisory subscription, and update cadence as web frameworks or container runtimes, not ad-hoc refreshes when convenient. Track upstream repositories and security channels directly; as of this writing, no CVE assignment, patch timeline, or SGLang maintainer comment had been published in connection with the incident, so teams should watch upstream advisories for concrete fix status.
Plan for blast radius beyond the compromised node. Assume that once code execution is achieved on one serving host, everything that host processed during the exposure window is in scope — including traffic that policy flags as confidential. Requests do not become opaque at the enclave's edge for the purposes of host-level attackers. Segment inference workers, restrict lateral movement, and log what each node processed so the blast radius of a future incident can be bounded rather than guessed.
Revisit what confidential mode promises users. If marketing language implies unbreachable privacy, the gap between that expectation and host-level visibility becomes a disclosure and trust problem, not just a technical one. Communicating TEE boundaries accurately — protection against a curious operator, not against a compromised host running the enclave — prevents precisely this kind of post-incident surprise.
The open questions remain upstream: no CVE, no stated patch window, no maintainer response so far. Until those land, the safe posture for anyone running an open-source inference engine in production is to assume the flaw is unpatched and to check upstream repositories directly.
Source: The Hacker News, 10 November 2026.
SGLang——這套開源大型語言模型推理引擎——的一個遠端執行碼（RCE）漏洞，讓攻擊者在上星期日取得 NEAR AI 其中一台推理伺服器的立足點；更關鍵的是，對方因此能看到用戶原以為全程在可信執行環境（TEE）內處理的請求。據 The Hacker News 報道，公司稱事件影響 18 個 agent 及約 100 名用戶。
事件由 NEAR AI 於本週初披露、The Hacker News 跟進報道，對「保密運算保護什麼、不保護什麼」而言是一則有用的案例。用戶透過 NEAR AI「保密模式」提交的請求，會在 TEE 內處理——這是一個以硬件隔離的 enclave，設計初衷是令數據對主機營運者亦不透明。但攻擊者從來毋須攻破 enclave。透過利用 SGLang 在底層伺服器上執行代碼，對方「可能已看到」該機器當日處理中的請求，包括經保密模式路由的請求——這番措辭看來是有意保守披露，暗示 enclave 的內部並未被攻破。
這個區分正是事件的核心。TEE 只能證明其邊界「之內」發生的事：記憶體經加密、attestation 報告會驗證經量度的代碼、密鑰只會釋放予帶有良好 quote 的代碼。越過該邊界的每一件事——進入前抵達的請求、離開後輸出的回應，以及主機一側的 attestation 及密鑰處理機制本身——都在完整性必須假設可信的基礎架構上運行。主機層級的執行代碼立足點，正好落在這些邊界之上。保密運算收窄了信任面，但並未消除對主機完整性的需要。
事件涉及的數字令這抽象概念有了具體分量：18 個 agent、約 100 名用戶、一部受入侵的推理伺服器，以及僅限該機器當日流量的可見窗口。對於自行託管開源推理堆疊的團隊而言，事件與其說是反對開源的理據，不如說是促使人反思補丁週期中 serving engine 及 orchestration 層受重視程度的理據。SGLang 一類組件常被當作管道部署——作為相依項目引入、鮮有人審閱、更新頻率遠低於所伺服的模型——然而它們在 enclave 邊界前後，以明文處理每一項請求。
給基礎架構團隊的三點實務啟示：
將推理引擎列為一等安全相依項目。 SGLang、vLLM 及同類 runtime 應獲與 web framework 或 container runtime 同等的監控、安全通告訂閱及更新節奏，而非方便時才臨時刷新。應直接追蹤上游 repository 及安全渠道；截至本文撰寫時，事件仍未見 CVE 編號、補丁時間表或 SGLang 維護者評論發表，故團隊應留意上游通告以掌握具體修復進度。
規劃爆炸半徑時須涵蓋受入侵節點以外範圍。 一旦在某部 serving host 上取得執行代碼能力，該主機在暴露窗口期間處理的一切均在影響範圍之內——包括被政策標記為保密的流量。對主機層級攻擊者而言，請求並不會在 enclave 邊緣才變成不透明。應分隔 inference worker、限制橫向移動，並記錄每個節點處理過什麼，令日後事件的爆炸半徑可被界定而非靠估計。
重新檢視保密模式對用戶的承諾。 若市場用語暗示無可突破的私隱，該預期與主機層級可見性之間的落差便會成為披露及信任問題，而不僅是技術問題。準確傳達 TEE 邊界——防的是好奇的營運者，而非被入侵但正運行 enclave 的主機——正是為了避免此類事後意外。
未決問題仍在上游：沒有 CVE、沒有已聲明的補丁窗口、至今沒有維護者回應。在此之前，任何在生產環境運行開源推理引擎的人，安全姿態應是假設漏洞尚未修補，並直接查閱上游 repository。
來源：The Hacker News，2026 年 11 月 10 日。