A newly disclosed critical vulnerability in the Linux kernel — nicknamed PwnEscape and tracked as CVE-2026-99999 — allows code running inside a virtual machine to read memory belonging to the host system it runs on, The Hacker News reported on 6 October.
The flaw is understood to reside in the Linux kernel's networking subsystem rather than in the configuration of any individual cloud provider, which means the risk extends broadly to shared kernel builds used across hosted and on-premises virtualization environments.
What was demonstrated
A researcher publicly demonstrated the issue against Vercel's live cloud sandbox infrastructure, successfully leaking host-side memory from inside a guest environment. Vercel confirmed the finding, according to the report. The choice of target drew attention: cloud sandboxes are among the most densely multi-tenant workloads in production, which makes them a useful stress test for any shared-kernel isolation model.
While the demonstration targeted a specific commercial sandbox product, the underlying defect is in common kernel code, not in Vercel's isolation stack per se. That distinction matters: virtualization platforms that share a single host kernel across many tenants — cloud sandboxes, container hosts, hosted CI runners, and multi-tenant VM farms — inherit the exposure regardless of how carefully the individual guest environments are configured.
Why kernel-level memory leaks are serious
Traditional VM isolation assumes that guest code can observe only virtualised resources assigned to it. A bug that lets a guest read host memory breaks that assumption at the hypervisor boundary's weakest layer: the shared kernel.
Host memory can contain secrets from other tenants, session tokens, cryptographic keys, and credentials belonging to management services. Even a read-only primitive of this kind can be chained into broader compromises, and it undermines the multi-tenant trust model that cloud providers depend on. A disclosure of this type can also defeat kernel address-space randomisation, removing a defence that makes follow-on exploitation harder.
Because the vulnerability sits in the kernel's networking code path, an attacker-controlled workload with ordinary network access inside a guest may be able to trigger the leak without needing elevated privileges within that guest — though the precise exploitation requirements were not detailed in the summary available to us.
Affected versions and mitigations
The source material available to us did not enumerate the specific kernel version ranges affected, nor did it name the release in which a fix ships. Organisations running multi-tenant virtualization should consult upstream kernel advisories and their distribution vendor's security bulletins directly rather than relying on secondary reporting.
As general guidance pending patch availability:
- Inventory kernel versions on all hypervisor and container-host nodes, particularly those hosting untrusted or multi-tenant workloads.
- Prioritise patching at the host level. Guests inherit the host kernel, so the fix cannot be applied from inside individual VMs; after upgrading a host, recycle guests booted before the patch so they are not still running vulnerable code.
- Review sandbox architectures that share one host kernel across many isolated guests; consider stricter workload separation for high-sensitivity tenants.
- Apply layered controls — network egress restrictions and workload identity boundaries — so that a kernel-level leak is harder to turn into lateral movement.
- Watch for indicators once upstream analysis publishes them: unusual cross-tenant memory reads or anomalous network-facing behaviour from sandboxed workloads warrant closer inspection.
The bigger picture
PwnEscape is a reminder that boundary security is not a property of guest configuration alone. For shared-kernel architectures — the model most cloud sandboxes use — isolation strength ultimately rests on the host kernel every guest inherits. For infrastructure teams across the industry, including those in Hong Kong operating multi-tenant hosting, CI/CD, or managed VM services, the practical takeaway is that kernel patch cadence is a first-order isolation control, not routine housekeeping.
This story also lands at a sensitive time for regulated sectors: institutions that rely on shared infrastructure to process customer data will want to confirm, with their providers, which host kernel builds underpin their environments and when those builds will be patched. Providers running dedicated host kernels per tenant, or offering hardware-backed isolation such as AMD SEV or Intel TDX, should be able to answer that question differently from shared-kernel competitors — and a distinct answer is itself a useful signal about how much of the shared-kernel risk model actually applies to you. That is a question worth asking before an advisory lands, not after.
We will update this article once upstream advisories confirm affected version ranges and patched releases.
Source: The Hacker News
Linux 核心近日披露一項嚴重漏洞，代號 PwnEscape，編號 CVE-2026-99999。The Hacker News 已於 10 月 6 日報道，該漏洞容許在虛擬機內執行的代碼，讀取其運行所在主機系統的記憶體。
據了解，該缺陷位於 Linux 核心的網絡子系統，而非任何個別雲端服務商的配置問題。這意味著風險廣泛影響託管及本地虛擬化環境所採用的共用核心建置版本（shared kernel builds）。
演示內容
有研究人員針對 Vercel 的實時雲端 sandbox 基礎設施公開演示了此問題，成功由 guest 環境內部洩露主機端記憶體。根據報道，Vercel 已確認該發現。所選的測試目標引人注目：雲端 sandbox 是生產環境中多租戶密度最高的工作負載之一，因此是測試任何共用核心隔離模型的理想壓力測試。
雖然演示針對的是特定商業 sandbox 產品，但底層缺陷位於共通的核心代碼，而非 Vercel 的隔離堆疊（isolation stack）本身。這點十分重要：凡是跨多個租戶共用單一主機核心的虛擬化平台——包括雲端 sandbox、container host、託管 CI runner，以及多租戶虛擬機叢集（VM farm）——都會承繼此風險，無論個別 guest 環境的配置有多嚴謹。
為何核心層級的記憶體洩露問題嚴重
傳統虛擬機隔離的前提是，guest 代碼只能觀察到分配予它的虛擬化資源。此漏洞容許 guest 讀取主機記憶體，打破了這項前提，失效位置正是 hypervisor 邊界中最薄弱的一層：共用核心。
主機記憶體可能包含其他租戶的機密資料、session token、加密密鑰，以及管理服務的憑證。即使只是只讀能力（read-only primitive），亦可連鎖擴大造成更廣泛的入侵，並動搖雲端服務商賴以運作的多租戶信任模型。此類洩露亦可擊破 kernel address-space randomisation（KASLR），移除一項令後續利用更困難的防禦機制。
由於漏洞位於核心的網絡代碼路徑上，攻擊者控制的工作負載即使只在 guest 內具備一般網絡存取權限，亦可能觸發洩露，無需在該 guest 內取得提權——惟我們可取得的摘要並未詳述具體利用條件。
受影響版本及緩解措施
我們取得的原始資料並未列明受影響的具體核心版本範圍，亦未指出修復方案將於哪個版本推出。運行多租戶虛擬化的機構，應直接查閱上游核心公告（upstream kernel advisories）及所用發行版供應商的安全通報，而非依賴二手報道。
在補丁推出前，一般指引如下：
- 盤點所有 hypervisor 及 container host 節點的核心版本，尤其是承載不受信任或多租戶工作負載的節點。
- 優先在主機層級進行修補。 guest 會承繼主機核心，因此無法從個別虛擬機內部套用修復；主機升級後，須重新啟動在補丁推出前已啟動的 guest，以免其仍在執行含有漏洞的代碼。
- 檢視 sandbox 架構，即跨多個隔離 guest 共用單一主機核心的模式；對高敏感度租戶應考慮實施更嚴格的工作負載分隔。
- 實施分層防禦——包括網絡 egress 限制及工作負載身份邊界——令核心層級的洩露難以進一步轉化為橫向移動（lateral movement）。
- 留意指標：一旦上游分析公布相關指標，若發現異常的跨租戶記憶體讀取，或 sandbox 工作負載出現不正常的對外網絡行為，即應深入檢查。
更宏觀的意義
PwnEscape 提醒我們，邊界安全並非單靠 guest 配置即可保障。對於共用核心架構——即大多數雲端 sandbox 採用的模式——隔離強度最終取決於每個 guest 所承繼的主機核心。對於業界各機構的基礎設施團隊，包括香港運營多租戶託管、CI/CD 或託管虛擬機服務的團隊，實際的啟示是：核心修補節奏（kernel patch cadence）屬於首要的隔離控制措施，而非例行維護事項。
這則消息亦適逢受監管行業的敏感時刻：依賴共用基礎設施處理客戶數據的機構，應與服務供應商確認其運行環境所依賴的主機核心建置版本，以及何時會進行修補。凡為每個租戶運行專用主機核心，或提供硬件支援隔離（如 AMD SEV 或 Intel TDX）的供應商，其答案應與共用核心的同業有所不同——而答案本身的不同，就是一項有用的指標，反映出共用核心風險模型對你實際適用的程度。這個問題值得在安全公告發出之前提出，而非事後才追問。
待上游公告確認受影響版本範圍及修復版本後，我們將更新本文。
資料來源：The Hacker News