小編精選 - 技術文章翻譯 · 10月17日

解讀 CVE-2026-99999（PwnEscape）──不是「KVM 的弱點」，而是 Linux 網路堆疊的弱點

工程負責課題提示・取捨選擇・內容檢查
筆者原案製作・編成 Claude Fable 5.1
事實查核（檢證備忘） GPT-6 Astra
一次資料對照・最終稿 Claude Fable 5.1

本稿是筆者個人的分析，並非所屬組織或各事業者的官方見解。基準日為 2026 年 10 月 16 日（資料確認 21:24 JST）。CVE、修正版、各事業者的對應狀況都可能變動，因此在判斷是否適用時，請再次確認原始資料與自身環境。本文中的參照編號 [n] 對應文末「參照」中的根據 URL。

本稿中「確認」的範圍
本稿是基於公開資料比對所做的風險研判，並非筆者親自進行攻擊重現試驗，也不是對各事業者非公開配置的稽核。研究者的實驗結果、事業者的公開說明、以及筆者的分析，會分開書寫。※ 表示本稿無法確認的事項，並不代表「未修正」「不適用」或「該事實不存在」。

結論

缺陷所在不是 KVM 本體，而是 Linux 核心的網路堆疊。由來自 guest 的不正確 checksum offload 中繼資料，會在主機端把已驗證的 IPv4 標頭後續改寫。即使是沒有使用 VM 的 TUN／AF_PACKET 路徑也在考慮範圍內，因此不能理解為「與 Linux guest 本身無關」[3][15]。
公開報告中，存在三種實證範圍不同的影響：主機記憶體外洩、主機可用性受損、以及在主機端管理者權限下的程式碼執行。Vercel 正式環境 Sandbox 中被證實的是主機記憶體外洩；當機與程式碼執行則是在研究者自有環境中報告的。僅憑已確認有外洩，不能推論所有環境都能一路拿到 root [13][15]。
CVE-2026-99999 已正式公開，CNA 的 CVSS v3.1 基本分數為 9.3／Critical。mainline 與主要 stable 系列都已納入修正。 AWS 對其管理服務「無影響」的公告，以及さくら的調查與預防性處置，將在第 5 節分開整理。實務上要確認的是：「受影響的 Linux 位於哪一層」「由誰管理」「是否確實在已修正的核心上運行」[2][10][16]。

1. 事實關係的確認

CVE 與修正

CVE-2026-99999 已正式編號並公開。 Linux CNA 記錄的公開時間為 2026 年 10 月 15 日 12:19 UTC（21:19 JST），狀態為 PUBLISHED，對應修正為 6785011f8b16。CNA 的 CVSS v3.1 基本分數為 9.3（Critical），向量為 AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。 CNA 所描述的 guest→host 路徑中，AV:L 表示透過 guest／虛擬裝置路徑，而不是一般僅靠 Internet 收到封包就能發動的攻擊。PR:N 的意思是，此路徑不需要主機端憑證、capability 或直接存取 /dev/net/tun，但仍需要 guest 能送出不正確的中繼資料。這不代表在不透過 VM 的 TUN／AF_PACKET 情境下，也同樣不需要權限條件[1][2][30]。
修正提交：torvalds/linux 6785011f8b16「ipv4: validate checksum_start before completing checksum」（作者 Michael S. Tsirkin，簽署使用 Red Hat 電子郵件地址／提交者 Jakub Kicinski，Cc: stable）。提交訊息重點是：若不正確的 checksum 中繼資料進入 IPv4 堆疊，skb_checksum_help 可能破壞網路標頭；Paulos 發現並回報後，其他人也獨立重現；後續希望再做更完整的入口驗證，但先在完成處理前加入防禦性檢查 [3]。
Fixes 標籤的對象：f43798c（tun: Allow GSO using virtio_net_hdr，2008 年 7 月）與 bfd5f4a（packet: Add GSO/csum offload support，2010 年 2 月）。CNA 將影響起始版本定為 2.6.27。AWS 公告中提到「4.4～6.18 的未修正核心」是另一種範圍表述，不能把它當成涵蓋 Linux 全部影響／不影響版本的完整清單。是否受影響要看程式碼是否存在、實際是否能被攻擊到，以及修正是否已套用，不能只看版本號 [4][2][10]。
修改 6 個檔案、保護 5 個位置：① 在 include/net/ip.h 新增共通防護 ip_check_csum_start()，② net/ipv4/ip_output.c 的 ip_do_fragment，③ net/bridge/netfilter/nf_conntrack_bridge.c 的 nf_br_ip_fragment，④ net/netfilter/nfnetlink_queue.c 的 nf_queue_checksum_help，⑤ net/netfilter/xt_CHECKSUM.c 的 checksum_tg（CHECKSUM target），⑥ net/xfrm/xfrm_output.c 的 xfrm_output。新增 44 行、刪除 12 行 [3]。

/* 新增到 include/net/ip.h 的共通防護 */
static inline int ip_check_csum_start(const struct sk_buff *skb)
{
    if (unlikely(skb->csum_start <
                 skb->network_header + ip_hdrlen(skb)))
        return -EINVAL;
    return 0;
}

/* ip_do_fragment() 修正後的順序：先檢查，再完成 */
if (skb->ip_summed == CHECKSUM_PARTIAL) {
    err = ip_check_csum_start(skb);
    if (!err)
        err = skb_checksum_help(skb);
    if (err)
        goto fail;
}

Vercel 的公開說明之整合

Vercel 將「Linux 核心的零時差漏洞 1 件」視為最重要發現，說明 Paulos Yibelo（pwn.ai）是從未被賦予特殊存取權的標準 Sandbox 中找到網路堆疊缺陷，而當機與程式碼執行則是在研究者自己的 KVM／Firecracker 環境中證實。由於多數大型雲端都在相同層級隔離客戶工作負載，因此這被視為共享基礎設施的風險。徵件時的威脅模型已涵蓋容器內 root、microVM 內核心存取，所以不能把它理解成「guest OS 內也是非特權」[13][14]。
初期報導曾把它描述為「記憶體外洩與主機當機兩個獨立缺陷」，但 10 月 14 日的 Vercel 官方說法則是：由單一網路缺陷即可解釋外洩、當機與程式碼執行 [32][13]。
Vercel 的數字：收件回報 1,285 件、有效回報 57 件、已支付獎金總額 242,000 美元、Critical 1 件。研究者個人獎金在報導中為 50,000 美元（與每件挑戰回報上限相同），但實際支付金額的一次資料尚未確認（※）[13][14][32]

名稱上的注意
「KVM escape」這個稱呼，是指研究者的實證跨越了 guest／host 邊界，並不表示脆弱點本身位於 KVM（文章本身在 Figure 1 已明確指出，修正對象也是 IPv4、netfilter、xfrm）。早期報導仍有把它混同成 KVM 自身缺陷的混亂，因此不要被標題帶著走 [3][15]。

2. 技術性機制的要點

CHECKSUM_PARTIAL 會讓 skb 帶有一個約定：「之後要把 checksum 寫到 csum_start + csum_offset 的位置」。guest 可以透過 virtio-net header 指定這個值。問題不在 IPv4 header checksum offload 本身，而是錯誤的位置指定會改寫到網路標頭 [26][15]。
研究者指出入口處（__virtio_net_hdr_to_skb）原本的最小長度檢查，只能檢驗相對於 skb->data 的條件，無法保證在移除 L2 header 後，對於「network header」的相對位置是正確的（座標系不一致）[15][3]。
在主機端的輸出分片處理 ip_do_fragment() 中，原本順序是「先完成 checksum，再取得 IP header 與讀取 ihl」，因此延遲寫入可能把 IPv4 header 開頭改掉，例如 0x45 變成 0x4f、IHL 從 5 個字變成 15 個字，讓原本已被當作 20 位元組驗證與路由的標頭，重新被解讀成 60 位元組 [15][3]。
研究者的測試案例中，線性資料 28 位元組會被複製成 60 位元組 header，因此差額的 32 位元組會以「IP option」的形式帶出，成為主機記憶體資訊外洩（這是對 skb 邏輯邊界的 OOB read，不是對 allocator 物理邊界的越界）。32 位元組只是這個案例的數值，不是固定量或上限 [15][3]。

封包外觀
起始位元／IHL／被解讀的 IPv4 header 長度／解析時狀態
0x45／5 個字／20 位元組／延遲寫入前
0x4f／15 個字／60 位元組／延遲寫入後

以下是研究者說明的 IPv4 分片路徑示意圖，並不代表所有配置都共用相同處理順序 [15][3]。

總之，這是「同一個封包在核心不同位置被當成不同狀態來信任」的 TOCTOU 型問題。這不是執行緒競爭，而是驗證與後續使用之間插入了延遲寫入的決定性處理順序問題。研究者把這種模式稱為「deferred-metadata trust inversion」，但同時也說其中包含已知技術。這個名稱與新穎性評價是研究者的主張，不應視為已確立的分類名，或是其他協定／產品有同類漏洞的證據 [15][2]。

3. 風險評估

攻擊者的立場、條件

必要條件是同時具備：可接受帶有惡意 offload 中繼資料封包的入口（virtio-net→TAP，或 TUN／PACKET_VNET_HDR 的 AF_PACKET），以及在未修正 Linux 上能到達相對應完成處理的路徑。guest root 通常是典型條件，但不是普遍充分條件；也不需要 hypervisor 本身有 bug [2][3]。
公開修正所保護的到達點共有 5 處（ip_do_fragment、bridge conntrack 的 fragment、NFQUEUE、CHECKSUM target、xfrm 輸出）。通常會考慮 host 對 guest 流量進行 routing／NAT 並做 IP fragmentation 的架構，但不能只靠產品名稱如「default NAT」就判定成敗。反過來，走 bridge conntrack 的架構也存在，所以也不能因為叫做「L2 bridge」就直接判定安全。這些是公開修正的保護目標，不是涵蓋所有變種的必要條件清單 [3][15]。
即使沒有 VM 也可能成立。 研究者初期 patch 的說明明確指出，不需要 VM guest，TUN 裝置就足以處理 virtio-net header，而且也包含對 AF_PACKET 端的檢查修正。從容器／user namespace 能否到達，取決於建立 TUN 所需的 CAP_NET_ADMIN、建立 AF_PACKET socket 所需的 CAP_NET_RAW（在管理該 network namespace 的 user namespace 中）、所傳遞的檔案描述元，以及後續路徑各自的條件。標準容器設定下是否能完整攻擊成功，尚未確認（※）[15][7][27][28]。

影響的嚴重度

報告中的影響實證狀況與意義：

主機記憶體外洩（每次測試案例約 32 位元組）：研究者已在對照實驗下重現。Vercel 也正式承認其生產 Sandbox 中曾證實主機記憶體外洩（但該公司表示，沒有報告顯示可存取客戶資料）[15][13]。
這屬於多租戶環境中的「機密性」破壞，可能有助於後續攻擊推估 KASLR／heap 狀態；但並未證實可任意位置讀取，也沒有證實能取得其他租戶資料。
主機 DoS：在研究者自有的 Linux 6.12 與 7.x 系列主機上確認（依文章原文）。至於所有 sub-version／設定範圍是否都能重現，尚未確認（※）[15][13]。
若該 Linux 因當機而停擺，可能使依賴它的 VM 群組出現停機／不可用；但若是巢狀中介主機或單一 VM 內的 Linux，並不等於會直接讓下層物理主機或所有其他租戶一起停擺。
64 位元有選擇性的核心寫入 → host root：研究者報告在自己的 KVM 實驗環境中，透過四次不同的 cold boot，重現了以主機 root 權限執行 helper 的結果。Vercel 也明確把當機／程式碼執行與研究者自有機器上的實證區分開來 [15][13]。
這應被視為研究者實驗環境中的 guest→host 邊界突破報告，而不是已證實對所有產品、所有配置都能做任意位址通用寫入，或已在供應商正式環境取得 root。

漏洞利用擴散的可能性

目前確認到的研究文章 Part 1 並未公開完整 exploit code，並預告會有處理 host 控制流程的 Part 2。對於第三方包含的所有公開位置是否已有 PoC 或續篇，尚未確認（※）。研究者預測：較弱配置的 exploit 可能在數週內出現，預設配置則可能在 1 個月內出現；但這不代表已確認了所有目標預設配置的範圍，也不代表實際完成與流通的時間已確認。筆者的風險判斷是：不要把這個預測當成截止期限或安全緩衝期，而應優先依據已公開的修正與自身組織的暴露條件來更新。[15]

誰是當事者

評估對象：以 Linux 核心為 host，並透過 virtio-net／TAP 等接受 guest 中繼資料的虛擬化／沙盒基礎設施（KVM/QEMU、Firecracker、Proxmox、OpenStack、oVirt、Linux 上執行的 crosvm 等 VMM、AI agent 用 sandbox）。Linux host 的存在，並不足以單獨構成受影響條件。 需要確認修正狀態、虛擬 NIC、是否接受中繼資料、Linux skb 路徑與後續處理，不能只看產品名稱。若使用 vhost-user／DPDK／SR-IOV，也不能只看技術名，還要確認目標流量是否會經過有問題的 Linux skb 處理，還是途中會回到 TAP 等。沒有 VM、而是處理 TUN／AF_PACKET 輸入的 Linux，也一併列入評估 [2][25][19]。
非 Linux 基礎設施與其上層 Linux 要分開看：VMware ESXi 的 VMkernel 或 Windows Hyper-V 本身，並不是這次 Linux 程式碼的直接修正對象。Azure 的基礎也被 Microsoft 說明為 Windows Hyper-V 架構。僅因為在跑 Linux VM，並不代表承載它的 ESXi 或 Hyper-V 物理主機會因本件變得脆弱。 但如果 guest 內的 Linux 能透過 TUN／AF_PACKET 等到達相關處理，或該 Linux 本身還是 KVM 等 host，就要另行評估該 Linux 的影響。要分清楚是哪一個 Linux 會受影響，以及要跨越哪一層邊界 [3][2][22][27][28]。
gVisor／Kata Containers：gVisor 有自己的 user-space 網路堆疊，但 host 接法不同，邊界也不同；Kata 則使用 VM，因此需要依所選 VMM、host kernel 與 backend 分別評估。不能說「因為是 container 所以不適用」，也不能說「因為是 VM 型就全部適用」（構成別影響判定尚未確認 ※）[23][24]。
IPv6：已採用的修正與因 IHL 改寫而導致外洩的實證，都是以 IPv4 為對象。原文提到，入口驗證的討論也與 IPv6、巢狀 header 有關，但本稿尚未確認 IPv6 有同樣的外洩或 root 取得實證（※）。這不代表「IPv6 沒有相關問題」，也不能導出「切換成 IPv6 就安全」[3][15]。

若把本組織的 Linux 是否屬於評估對象畫成流程圖，會是下面這樣。

4. 修正散布的現況（10 月 16 日時點）

対象狀況mainline 10 月 8 日 Jakub Kicinski 已套用到 net.git（patchwork bot 通知）。同日對 Linus 的 pull request（Networking for v7.3-rc7）於10 月 9 日合併（合併提交 af32da41、標籤 net-7.3-rc7）。pwn.ai 文章中寫成「10 月 14 日合併」與公開歷史不符 [5][6][15]
stable：CNA 記錄中所示各 stable 系列修正版為 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11。10 月 15 日的發行也可從 6.1.190 與 7.2.11 的變更紀錄確認到對應修正。對 7.0／7.1 是否有個別 backport，本稿尚未確認（※），因此不能解讀成「7.x 全系列都已修正」[2][9]
Amazon Linux：AWS Security Bulletin 2026-137-AWS 於 10 月 15 日 10:30 PDT（10 月 16 日 02:30 JST）發布。AL2：kernel-4.14.355-287.750.amzn2、kernel-5.4.302-229.494.amzn2、kernel-5.10.269-270.1108.amzn2、kernel-5.15.220-156.256.amzn2。AL2023：kernel-6.1.188-233.385.amzn2023、kernel-6.12-6.12.110-135.201.amzn2023、kernel-6.18-6.18.51-120.162.amzn2023。公告將這些版本之後視為已修正。即使上游版本號比較小，也可能是已 backport 修正的版本。 對自行管理的 host，AWS 的建議是套用更新套件並重新啟動，沒有提供繞過方式 [10]
Debian／Ubuntu：Debian 官方 tracker 顯示，來源套件 linux 的 sid 7.2.11-1 為 fixed，bookworm、trixie、forky 列出的版本則標示為 vulnerable。Ubuntu 官方頁面有 Needs evaluation 的系列。「評估中」不能被解讀成「確定脆弱」或「確定已修正」。 必須逐一比對自己的發行版、核心系列與實際執行中的 build [11][12]
RHEL／Rocky／SUSE／Proxmox：尚未完整確認修正版範圍（※）。請以各家公告為準。
Live patch：對 kpatch／livepatch／Ksplice 等機制，是否已提供能對應本 CVE 的修正、可套用的 build 與實際套用狀態，本稿都未確認（※）。可使用這類機制，與這個 CVE 的修正已啟用，是兩回事。AWS 已確認的指示仍是：更新並重新啟動自行管理的 host [10]
入口端（virtio_net_hdr 驗證）後續修正採納狀況：已採納的提交說明，更完整的輸入驗證還需要額外工作。公開郵件列表上，10 月 7 日 Willem de Bruijn 的提案在 10 月 8 日被要求重新提交（Changes Requested），而 10 月 15 日 Tsirkin 的 v2 系列（7 個補丁）則投稿到 net-next。不過，這是本稿在 10 月 16 日時確認到的投稿與審查階段狀態，各提案最新是否已接受、是否已收錄到哪個版本，尚未確認（※）。應把針對已知 IPv4 header 改寫的修正，與整體輸入 API 的驗證強化區分開來；不能因為後續提案還在等待，就延後既有修正的套用 [3][15][8]。

5. 雲端業者的對應狀況

AWS：明確表示「EC2 執行個體、Lambda、Fargate 等 AWS 管理的運算與容器服務不受影響，使用者無需採取動作」。受影響的，是「在未修正主機上，透過 virtio-net 和 KVM 自行管理 VM（包含使用 Firecracker 等 VMM）的使用者」。AWS 對 Nitro 的說明是「以 KVM 為基礎自行開發並最小化的 hypervisor」，因此說它是「KVM-based」是合理的；但把它推定為與一般 Linux＋QEMU＋TAP／vhost-net 完全相同的資料路徑是不適當的。Vercel Sandbox 是在 bare-metal EC2 上自行建置 Firecracker 基礎設施，因此 Vercel 主機上可證實發生的事件，與 AWS 管理服務無影響的公告並不矛盾 [10][18][14]。
さくら網際網路：10 月 16 日的全公司公告指出，截至當天 17:00，仍在確認服務是否受影響以及影響範圍。さくら雲端自同日起暫停新建專案，恢復時間會在確定後通知。既有專案可繼續使用，並說明暫停新建專案不會影響既有資源運作。這並不等於否定了漏洞本身或未來維護的影響。專用伺服器 PHY／高火力 PHY 若需要新建專案也暫時無法申請，且表示之後可能會實施包含 host 維護在內的對應。全公司公告也提醒，自行管理作業系統的服務，要依 OS、核心與配置確認供應方更新資訊。不要把這份公告解讀成所有 host 都已被證實脆弱或遭入侵[16][17]。
Google Cloud／OCI：可從官方文件確認 Compute Engine 使用基於 KVM 的 hypervisor，而 OCI 也以 KVM 的 Oracle Virtualization 為基礎；但本 CVE 的服務別影響判定／修正狀況尚未確認（※）。不能僅因為都採用 KVM，就直接判定為當事者 [20][21]。
Azure：Microsoft 說明其基礎 hypervisor 是 Windows Hyper-V，因此不能僅根據本件 Linux 程式碼，就主張其物理主機可被逃逸。不過，使用者自行管理的 Linux VM，或其中的自管虛擬化／沙盒，仍需另行評估。這是根據基礎架構公開說明所做的技術性整理，並不表示已取得 Azure 全服務對本 CVE 的個別影響判定 [22][3]。
沒有找到公告，既不能當成未處理的證據，也不能當成已處理的證據。

6. 公部門與地方自治體的觀點

本節是把前面公開資料套用到公部門運作的筆者分析，並不表示原始資料已對自治體或 GovCloud 的特定配置驗證過攻擊成功。

GovCloud 使用者：使用者無法更新 CSP 管理的物理 host。但也不是完全無能為力：可以確認受影響的服務與路徑、向 CSP 詢問（AWS 已公開管理服務無影響，さくら仍在調查，Google Cloud／OCI 為※）、確認委外單位建置的自管 Linux host（例如 bare-metal 上的 KVM）更新狀況、停止可疑工作負載等，這些都可在管理範圍內進行。應先釐清究竟是哪一台 Linux 在管理中 [10][17]。
「雲端＝相當於物理隔離」的含意：本件可作為某種共享 Linux host 配置下 guest→host 隔離邊界被破壞的案例說明。但這不代表已證實可取得其他租戶的客戶資料，也不代表所有雲端的隔離機制都會因同一缺陷而破壞，更不代表 GovCloud 曾以同樣方式被證實。請將「隔離方式的一般原理」與「本件對個別服務的影響確認」分開寫 [13][15]。
自治體／供應商的 on-prem KVM 基礎設施：如果三層分離的各層是透過 Proxmox／libvirt 等虛擬化，或使用 Linux KVM-based appliance，不能只看名稱就判定有漏洞，而要確認 Linux 的修正狀態與輸入／到達路徑。對會受影響的配置，套用發行版／供應商的已修正 build。若同一個 Linux host 共享了不同信任等級的 VM（例如連網系統與 LGWAN 系統、外包 VM 與機關內 VM 等），應優先檢討跨邊界風險。原始資料並未調查或實證自治體的三層分離架構，因此這是筆者的套用判斷 [3][2]。
AI agent 執行基礎設施：即使已阻斷對外通訊，只要前段 TAP／host 處理仍能接收到攻擊輸入，風險就仍在。相反地，若配置中根本沒有虛擬 NIC，也沒有 TUN／AF_PACKET 的替代輸入，就不能僅憑這條實證路徑說它危險。評估時要清楚說明「網路阻斷」是在哪一層實作的。不能用其他網路隔離繞過案例，來代替本件成立條件的證據 [2][15]。

7. 應採取的對策

對受影響的 Linux 套用含修正的支援版核心／供應商 build。 host 端漏洞不會因為只更新 guest 核心就被修正。另一方面，如果 guest 內 Linux 自身也有輸入路徑，則該 Linux 的更新也要另行判斷。不要只把單一提交無驗證地拉進來，應優先使用發行版／供應商已驗證的更新，並進行必要的重開機與運作確認。不要因為還在等 CVE 確認或後續輸入驗證方案，而延後已發布修正的套用 [3][10]。
區分「已安裝」與「正在執行」。比對供應商的已修正 build（例如 Amazon Linux 可能會出現比 upstream 更小的 base version number）與目前實際運行的核心／live patch 狀態 [10][2]。
監看後續入口驗證強化。 依已採用／已散布修正的內容，判斷是否還需要追加更新（目前不能斷言一定還要追加更新）[3][8]。
暫時降低暴露面可作為構成別的輔助措施。 以下是根據公開處理路徑做的技術性研判，並不是供應商保證的通用繞過方式。AWS 也沒有提供本件的繞過方法。
- 如果能避免 guest 來源流量走到 NFQUEUE／xfrm／CHECKSUM target 的相應完成處理，該路徑的暴露面就能降低。但不能只看模組是否存在，還要確認是否還有其他完成處理會被走到 [3]。
- 若能實際避免 host 上的 IPv4 fragmentation 處理，就能降低對該處理的暴露。不過只調整 MTU／MSS，未必能擋住惡意 guest 發出的所有封包，也無法對其他完成路徑提供對策 [3][15]。
- 關閉 checksum offload 的意義，會因 guest 端設定、virtio 功能協商、TAP 端設定、實體 NIC 端設定而不同。TUN 的實作註記提到，它不掌握 guest 協商好的功能，而輸出裝置不處理的 checksum 可能會回到軟體處理。關掉實體 NIC 等開關，和拒絕不正確的輸入中繼資料，並不是同一件事。 在未確認 VMM、backend、核心版本與實作前，不要直接下結論說「關閉 offload 就安全」[26][29]。
也要評估因配置變更導致的通訊中斷、效能下降等問題，不能把它當成修正套用的替代方案 [10]。
多租戶基礎設施要優先評估可用性影響。 如果處理攻擊輸入的 Linux host 發生當機，其上的 VM 群組可能也會停擺或無法使用。要確認關鍵業務影響、不同信任等級工作負載共置情形，以及更新時的避難與復原程序。不過，DoS 不能作為「一定會先於資訊外洩或程式碼執行」的預測，也不能因此省略機密性與完整性評估 [13][2]。
若要寫成報告／教材：應將缺陷所在寫成「Linux 核心的網路堆疊」，將已實證的路徑之一寫成「guest→host 邊界突破」。CVSS 的 AV:L、PR:N 要連同 CNA 對 microVM 路徑的前提一起呈現。不要把研究者自有環境的實證，擴大解釋成所有產品或所有供應商正式環境都能成功攻擊 [2][15]。

8. 揭露時間線

日期以原始資料的表述為基準。若涉及時區差異，則併記 UTC／PDT／JST。未公開的聯絡事項，視為研究者的揭露歷程，並非已獨立確認當時的郵件原稿。

日期（2026 年）	事件	來源
8 月 18 日	Vercel 公布 100 萬美元的 Sandbox 挑戰	Vercel 官方 [14]
8 月 20 日	研究者提交最初的主機記憶體外洩報告	研究者揭露歷程 [15]
9 月 4 日	向核心安全窗口與 netdev 維護者非公開回報根因與候選 patch	研究者揭露歷程 [15]
9 月 7 日	Michael S. Tsirkin 確認重現並收到候選 patch	研究者揭露歷程 [15]
9 月 19～22 日	在 netdev 上公開提交 patch 與修訂，review 範圍擴大	netdev [15][7]
9 月 25 日	予約 CVE-2026-99999	CVE 記錄 [2]
10 月 7 日	Tsirkin 提交修訂版防護；Willem de Bruijn 的入口驗證方案也提交（翌日被要求重提。各提案最新狀態請參考第 4 節的保留事項）	netdev [15][31]
10 月 8 日	受理至 net.git（patchwork bot）；送出給 Linus 的 pull request	netdev／LKML [6][15]
10 月 9 日	合併到 mainline（`af32da41`，net-7.3-rc7）	torvalds/linux [5]
10 月 14 日	Vercel 公布 challenge 結果	Vercel 官方 [13]
10 月 15 日	公開 CVE（12:19 UTC＝21:19 JST）。含修正的 stable release（可從 6.1.190／7.2.11 的變更紀錄確認日期）。AWS 公告（10:30 PDT＝10 月 16 日 02:30 JST）。入口端修正的 v2 系列投稿到 net-next（是否已受理／收錄為※）	CVE／kernel.org／AWS／netdev [2][9][10][8]
10 月 16 日	さくら網際網路發布全公司公告與雲端對應公告，並暫停新專案建立	さくら官方 [16][17]