當你的程式助理憑空發明一個套件，攻擊者會搶先一步註冊

要求 AI 程式助理整理匯入項目，它可能會給你一個根本不存在的套件名稱。這個名稱看起來很合理。它會結合兩個真實工具，或遵循你認得的命名慣例。你貼上安裝指令，而如果已經有人註冊了那個名稱，你就剛安裝了他們發布的任何東西。

安全研究人員稱此為 slopsquatting。它是錯字搶註的親戚，差別在於攻擊者不需要你打錯任何字。他們只需要知道模型傾向憑空發明什麼，然後搶先宣稱那個名稱。

規模並非個案

2025 年 USENIX Security 的一項研究，在 Python 和 JavaScript 的 576,000 個程式碼樣本上測試了 16 個程式碼生成模型。研究發現超過 205,000 個不存在於任何套件註冊庫的唯一套件名稱。商用模型的幻覺率至少為 5.2%，開源模型則為 21.7%。2026 年的一項後續研究測試了五個較新的前沿模型，測得比率介於 4.62% 到 6.10% 之間，雖然較低，但在每個受測模型中仍然存在。

把一個怪癖變成攻擊面的關鍵，在於可重現性。當研究人員重新執行相同的提示時，很大一部分的幻覺名稱每次都再次出現。模型不是在隨機亂猜；它們會收斂到相同的錯誤答案，因為它們從相同的訓練資料中學到了相同的模式。這種可預測性就是弱點。攻擊者可以執行相同的提示，收集重複出現的名稱，並搶在任何人之前註冊它們。

2026 年的研究找出了 127 個套件名稱，這五個受測模型全都產生了這些名稱，儘管它們並不存在；在套用註冊庫防護措施後，仍有 53 個可供註冊。

真實套件，真實安裝

這種事已經發生過。2026 年初，研究人員發現一個名為 react-codeshift 的套件在 237 個 GitHub 儲存庫中被引用。這個名稱混合了兩個真實工具：jscodeshift 和 react-codemod。它從未被發布。一個含有這個虛構套件的 AI 生成技能被複製和分支，讓這個引用自行散播開來。

npm 上一個名為 metro-evaluator 的套件，在 2025 年 12 月發布的四個版本中帶有惡意程式碼，五天後被移除，並替換成安全性佔位套件。受測模型曾十次建議這個名稱。另一個名為 unused-imports 的套件模仿了真實的 eslint-plugin-unused-imports，並持續吸引安裝——這些開發者的助理把他們引導到該套件。

更大的行動是安全公司 Koi Security 稱為 PhantomRaven 的攻擊行動，至少自 2025 年 8 月起活躍。Koi 將 126 個惡意 npm 套件和超過 86,000 次下載歸因於它。這裡的手法不同於幻覺名稱。package.json 看起來很乾淨，有時只包含一行日誌，但它指向一個以純 HTTP URL 託管的相依套件，而不是另一個 npm 套件。大多數掃描器不會追蹤原始 URL，因此竊取 npm token、GitHub 憑證和 CI 機密的酬載會在安裝時隱形載入。Endor Labs 記錄了同一波攻擊行動在 2025 年 11 月至 2026 年 2 月間的三波後續攻擊，新增 88 個套件，透過約 50 個免洗帳號上傳。

註冊庫封鎖了大多數名稱，但不是全部

研究中有個好消息。套件註冊庫已經更擅長封鎖模型傾向發明的名稱。它們會正規化相似名稱、維護禁用清單，並留意在許多生成樣本中出現的模式。當 2026 年的研究檢查其 127 個共享幻覺名稱清單時，大多數已被合法專案和註冊庫防禦機制搶先佔用或封鎖。

問題在於「大多數」不等於「全部」。同一項研究發現，套用防護措施後，仍有 53 個名稱可供註冊。只要有一個可註冊的名稱是多個前沿模型一致產生的，就足以圍繞它建構攻擊，因為攻擊者只需要猜模型，不需要猜開發者。註冊庫營運方已關上大部分的門；剩下的缺口雖窄，但仍敞開。

同樣的模式如今已蔓延到套件管理器之外。安全研究人員記錄了攻擊者註冊模型幻覺出的網域，以及代理可能憑空發明的儲存庫和技能。每個案例的機制如出一轍：模型預測出一個看似合理的名稱，而一個被設計成信任該預測的系統就會據此行動。代理能觸及的每個新表面，都成為另一個植入代理會去取用之名稱的地方。

為什麼代理會讓情況更糟

人類開發者或許會注意到可疑的套件名稱。代理不會。代理會自主安裝相依套件，通常沒有人先讀過指令。研究人員已展示提示注入技術，能誘騙代理要求攻擊者控制的套件名稱；在 Cursor、Windsurf 和 GitHub Copilot 等工具上，據報成功率最高達 100%。

這種組合改變了風險概況。幻覺提供名稱。代理提供執行。攻擊者只需等待兩者相遇。

外洩問題也是同一個問題

公司 Glow 的一份相關報告發現，代理在 GitHub 上暴露了超過 13,000 張內部圖片，來自 300 多個組織。機制很平常：代理及其使用者把截圖、圖表和文件放進公開儲存庫，有時並不理解「公開」意味著可被搜尋且永久留存。讓開發者更快的同樣工具，也讓內部資料更容易被移到不該去的地方。

這兩個問題共享同一個根本原因。代理以機器速度對可能錯誤（幻覺名稱）或敏感（內部截圖）的指令採取行動。過去介於意圖與行動之間的人為檢查點，正是代理移除的東西。

實際該怎麼做

防禦並不複雜，這算是好消息，因為威脅移動得很快。

把代理產生的每個安裝指令都當成不受信任的輸入。安裝前先確認套件存在。檢查它有多舊；已註冊的幻覺名稱會很年輕。檢查發布者是否有紀錄。對 npm 和 PyPI 而言，快速查一下中繼資料就能在幾秒內回答這三個問題。

要求代理新增相依套件之前必須有人工核准。這是單一最高價值的變更，因為它一次攔截幻覺名稱、惡意註冊和提示注入請求。它會讓代理稍微變慢，卻能補上最大的洞。

讓代理的觸及範圍保持最小。程式編寫代理需要儲存庫存取權；它很少需要正式環境憑證，也不該在沒有檢查的情況下，讓套件管理器指向私有註冊庫。Socket 和 Snyk 等工具可以在 IDE 或 CI 流程中自動查詢註冊庫；一旦團隊在多個儲存庫中使用代理，這就值得付出成本。

令人不安的部分是，這些都不是能被修補的錯誤。幻覺已深植於這些模型預測文字的方式：它們產生下一個看似合理的名稱，而不是經過驗證的名稱。修正必須存在於模型周圍的工作流程中，而這是大多數團隊本週就能開始的流程。