CISA聯合示警:中國六家AI業者以工業規模「蒸餾」竊取美系前沿模型能力
cisa.gov · 2026-09-08
NSA、CISA 與 FBI 於 2026 年 9 月 8 日聯合發布資安通報 AA26-251A,指控多家中國 AI 業者自 2024 年底起至 2026 年中,對美國前沿 AI 公司發動工業規模的知識蒸餾行動,並強調這類行動已構成這些業者研發策略的核心,而非附屬手段。通報點名 DeepSeek、Moonshot AI(月之暗面)、阿里巴巴集團、MiniMax、StepFun(階躍星辰)與 Z.AI 六家業者,鎖定對象為 Anthropic、OpenAI、Google 與 xAI 旗下的前沿模型。通報同時附上 MITRE ATLAS 對應的攻擊技術編號與緩解措施編號,供防禦端參照。
攻擊手法
知識蒸餾(distillation)原是機器學習中常見的模型壓縮技術:用大模型的輸出訓練一個更小、更便宜的模型,使其模仿大模型的行為。通報指出,這些業者刻意鎖定思維鏈(chain-of-thought)萃取——即誘使前沿模型揭露其隱藏的內部推理過程,而非僅擷取最終答案,因為思維鏈揭示了模型「如何思考」,是複製其推理能力的捷徑。取得思維鏈資料的手段包括提示注入(prompt injection)與越獄(jailbreak)技巧,迫使模型吐出原本會被拒答的推理內容。
基礎設施層面,通報描述了一個轉售存取權的灰色市場:所謂「轉運站」(transfer stations)以低於官方定價轉售 API 存取權,搭配未登記在真實使用者名下的偽造帳號、註冊資訊與付款方式高度相似的帳號群組,以及第三方 API 聚合器與雲端服務商通道進行分流。查詢模式上,單一主題可見「數千到數百萬次」的協同請求,新帳號註冊後立即以最大用量運作,而非逐步採用,並搭配大量採購企業級訂閱、於團隊間共用配額與快取以壓低成本。
- 灰色市場 API 代理(轉運站)與偽造/群組化帳號
- 思維鏈萃取、提示注入與越獄技巧
- 新帳號立即最大用量、企業訂閱與配額共用
- 偵測到封鎖時自動在多條路徑間failover
- 自動化清除請求中的組織識別資訊
- 建立品質評估框架以偵測對方的防禦反制措施
通報特別提到 MiniMax 具備近即時的監控與重定向能力,能在遭封鎖後 24 小時內调整策略重新接入目標模型,顯示部分業者已將反偵測本身系統化。通報還引用一則值得注意的評論:「DeepSeek 公開宣稱的 560 萬美元訓練成本具有誤導性,因為其中並未計入透過大規模惡意蒸餾取得資料的真實成本。」
鎖定目標
通報依業者列出各自鎖定的美系模型與意圖取得的能力範疇,顯示不同業者的蒸餾重點對應各自產品線的能力缺口。以下整理通報中列出的對應關係:
| 中國業者 | 鎖定的美系模型 | 意圖取得的能力 |
|---|---|---|
| DeepSeek(R1/V3) | Claude、GPT 系列 | 法律優化、規則驅動任務、思維鏈草稿、代理式功能、SFT 優化 |
| Moonshot AI(Kimi-K2/K3) | Claude、GPT 系列 | SFT、強化學習、軟體工程、數學能力、代理式推理與工具使用 |
| 阿里巴巴(Qwen 系列) | Claude、Gemini、GPT 系列 | 客服對話、虛擬角色生成、SFT/RL/蒸餾訓練、端到端代理式工作流程 |
| MiniMax(M2) | Claude(含操弄 Claude Code) | 思維鏈推理、RL、SFT、程式碼生成與分析 |
| StepFun(Step 4) | GPT、Gemini 系列 | 程式撰寫、代理式功能 |
| Z.AI | Claude、Grok 系列 | 思維鏈推理能力 |
通報列出的偵測指標包括:同一帳號來自多個 IP 與 user agent、全天候不間斷使用且無人類作息的空檔、訂閱等級與 API 用量比例異常、跨帳號池呈現一致的操作模式,以及在漏洞揭露後後設資料特徵突然消失等徵兆。
因應建議
通報對美國 AI 業者提出三項立即行動:建立異常提示、帳號、網路與行為的偵測與緩解機制,並監控訂閱與用量比例、新帳號立即最大用量與企業級吞吐模式;對疑似惡意蒸餾行為刻意調整回應內容以降低對方蒐集資料的報酬;跨模型供應商、雲端平台與 API 聚合器建立情資共享,以揭露分散式行動的全貌。
AML.M0015預測式 AI 對抗輸入偵測AML.M0004限制 AI 服務查詢量與速率AML.M0019控管正式環境中 AI 模型與資料的存取權AML.M0024AI 遙測日誌紀錄AML.M0002預測式 AI 輸出混淆AML.M0035AI 紅隊演練AML.M0003預測式 AI 模型強化
通報並提及可搭配差分隱私(differential privacy)機制,依每次查詢消耗的「隱私預算」限制資訊外洩量,並在訓練前後導入安全介入與對抗式訓練,同時以提示格式區隔使用者輸入與系統指令,降低提示注入的可行性。
Linux核心21個LPE漏洞齊發,「ZcopyReaper」源於RDS零拷貝清理競態
openwall.com · 2026-09-08
資安研究者 Yuan Tan 於 2026 年 9 月 8 日在 oss-security 郵件論壇揭露一批共 21 個 Linux 核心本地權限提升(LPE)漏洞,其中代號「ZcopyReaper」、編號 CVE-2026-43502 的漏洞最受關注,出在 RDS(Reliable Datagram Sockets)協定的零拷貝(zero-copy)清理邏輯。次日 Dominique Martinet 在同一討論串回覆補充其餘漏洞的技術細節與受影響版本。這批漏洞橫跨 RDS、SCTP、io_uring、XFRM、Netfilter、MPLS 與 Open vSwitch 等多個核心網路子系統。
漏洞機制
LPE(Local Privilege Escalation,本地權限提升)指攻擊者已取得系統上普通權限帳號後,利用核心或系統元件的缺陷取得 root 等更高權限。零拷貝(zero-copy)則是一種網路 I/O 最佳化技術,讓使用者空間的記憶體頁面直接「釘選」(pin)給核心用於傳送,省去資料在核心與使用者空間之間重複複製的開銷,常見於高吞吐網路協定與 io_uring 之類的非同步 I/O 機制。零拷貝的代價是核心必須精確追蹤這些被釘選頁面的生命週期,一旦追蹤邏輯出錯,就可能提早釋放仍被使用者引用的記憶體。
CVE-2026-43502 的根因正是如此:訊息清除(purge)路徑原本依賴 rm->m_rs 欄位判斷一則訊息是否屬於零拷貝,但零拷貝的真正歸屬其實由 op_mmp_znotifier 的存在與否決定,與訊息是否已排入 socket 佇列無關。當零拷貝傳送在使用者頁面已被釘選、但訊息尚未掛上傳送 socket 前失敗,清除路徑會誤判並依「一般承載頁面」的方式釋放這些頁面,造成釘選頁面被提前釋放,形成 use-after-free,本地低權限使用者可藉此觸發權限提升。該缺陷於 2018 年 2 月隨 4.17 版引入,已在上游修復。
受影響版本
本次揭露的漏洞清單橫跨多個核心子系統,以下整理討論串中列出技術細節的部分項目:
| CVE | 子系統 | 問題描述 | 受影響版本 |
|---|---|---|---|
CVE-2026-43502 | net/rds | 零拷貝傳送於訊息掛上佇列前的清除邏輯錯誤 | 4.17 起引入,已於所有穩定樹修復 |
CVE-2026-52929 | SCTP | stream:未完整回滾被拒絕的 add-stream 狀態 | 4.15 起引入,已修復 |
CVE-2026-52933 | io_uring | poll:io_poll_get_ownership() 中的有號數比較錯誤 | 6.1 起引入,已修復 |
CVE-2026-72137 | XFRM | nat_keepalive:傳送失敗時發生 double free | 6.11 起引入,已修復 |
CVE-2026-72255 | Netfilter | nf_queue:NFQUEUE 持有假 dst 時未釘選橋接裝置 | 5.10 版缺少修補 |
CVE-2026-43042 | MPLS | 缺少 seqcount 保護 platform_label(s) 配對 | 4.1–6.18 缺少修補 |
CVE-2026-31678 | Open vSwitch | tunnel netdev_put 延遲至 RCU release 執行 | 4.3–6.0 缺少修補 |
信件主旨標示此批共 21 個漏洞(ZcopyReaper 加上另外 20 個),但本討論串回覆僅列出上述數項的完整技術描述,其餘項目的細節在信中以指向 kernel.org 漏洞資料庫的方式帶過,未在本串內逐一展開。
修補與緩解
多數列出的漏洞已在所有穩定核心分支中修復,包括 ZcopyReaper 本身。Martinet 在回覆中提到 CVE-2026-72255(Netfilter)已有第三方送出修補提交,而 CVE-2026-43042(MPLS)與 CVE-2026-31678(Open vSwitch)則仍存在修補缺口,尚未覆蓋全部受影響版本區間。後兩者的觸發前提是攻擊者需具備網路命名空間(network namespace)存取權,限縮了實際可利用的場景。信中未附上任何 PoC 程式碼或修補 diff,僅指向上游 git.kernel.org/pub/scm/linux/security/vulns.git 的漏洞紀錄供查證各筆修復提交。
Astro修補GHSA-26w7-cxv4-gfx2:AVIF圖片最佳化經libheif觸發RCE
github.com · 2026-09-08
GitHub 資安公告資料庫於 2026 年 8 月 27 日發布 GHSA-26w7-cxv4-gfx2(9 月 8 日複查),指出 Web 框架 Astro 內建圖片服務 Sharp 所依賴的 libheif 函式庫存在記憶體錯誤,當 Astro 對惡意 AVIF 圖片進行最佳化處理時可導致遠端程式碼執行(RCE)。公告評為 Critical,CVSS v3 評分 9.8(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H),對應弱點分類 CWE-125(越界讀取)與 CWE-787(越界寫入)。
漏洞機制
公告本身描述精簡:「libheif 中的漏洞——Astro 預設圖片服務 Sharp 所依賴的函式庫——在最佳化惡意 AVIF 圖片時可導致遠端程式碼執行」,觸發前提是攻擊者能讓 Astro 處理不受信任的 AVIF 圖片,例如經由使用者上傳圖片後觸發的最佳化流程。libheif 是 HEIF/AVIF 格式的解碼與編碼函式庫,此類函式庫近年多次出現的漏洞型態,是解碼器在處理內含巢狀衍生參照(derivation reference)的畸形檔案時,建構出的中介影像描述與實際配置的緩衝區大小不一致,導致縮放或色彩轉換階段寫入超出配置範圍的記憶體。公告將此問題連結至上游 libheif 公告 GHSA-g89c-p67h-r497,顯示根因位於解碼器本身而非 Astro 或 Sharp 的整合邏輯。
受影響版本
受影響範圍為 Astro 7.2.8 以前的所有版本,修復版本為 7.2.8。此次修補的做法並非直接修改 Astro 程式碼,而是將內建 Sharp 依賴的最低版本上調至 0.35.4,以帶入 Sharp 團隊已修補 libheif 記憶體錯誤的版本。
- 受影響版本:
astro< 7.2.8 - 修復版本:
astro7.2.8 - 相依套件需求變更:
sharp最低版本調整為 0.35.4 - 上游根因公告:
GHSA-g89c-p67h-r497(libheif)
修補與緩解
修復由 commit ecb4082(對應 PR #17837「Update Sharp to 0.35.4」)完成,異動集中在 packages/astro/package.json 的相依版本宣告與對應的 lockfile:
// packages/astro/package.json
- "sharp": "^0.34.0 || ^0.35.0"
+ "sharp": "^0.35.4"
由於此為相依套件最低版本的硬性限制,而非新增程式邏輯,升級至 Astro 7.2.8 並重新安裝相依套件即可套用修復,無需額外設定變更。在完成升級前,任何允許處理外部或使用者提供 AVIF 圖片的 Astro 圖片最佳化端點都應被視為存在風險。
原始來源:GitHub Security Advisory GHSA-26w7-cxv4-gfx2、修復 commit ecb4082