Slopsquatting：五分之一 AI 程式碼樣本推薦不存在的套件

Slopsquatting：五分之一的 AI 程式碼樣本會推薦不存在的套件

Typosquatting 需要你犯錯；Slopsquatting 完全不需要你出手。犯錯的是模型，攻擊者只需註冊模型生成的名稱。

這個名稱源自 Python Software Foundation 的 Seth Larson：把 typosquatting 中的 typo 去掉，再加上 slop。

如果你使用 AI 程式編寫助手，一定見過這種情況。它會虛構一個套件，例如看似合理的 strutils-pro，或是聽起來非常官方的 secure-random。安裝失敗，你聳聳肩，然後繼續做其他事。

安裝失敗反而是較好的結果。較糟的情況是安裝順利完成，因為有人已搶先註冊該名稱。

五分之一：實測結果

目前最大規模的測量研究由 UT San Antonio、University of Oklahoma 和 Virginia Tech 的研究人員進行，並於 USENIX Security 2025 發表。他們使用 16 個程式碼生成模型，以 Python 和 JavaScript 生成223 萬個程式碼樣本，並逐一核對每個匯入項目是否存在於 PyPI 和 npm 的實際套件庫中。

19.7% 的樣本至少包含一個不存在的套件。

不是已棄用的 API，也不是有錯誤的程式碼，而是模型以十足把握生成的虛構匯入陳述式。

這些樣本中有 440,445 個包含共 205,474 個不同的虛構名稱。分佈情況與總數同樣重要：開放權重模型平均有 21.7% 的情況會虛構套件，商用模型則為 5.2%。CodeLlama 系列模型在某些配置下超過 33%。表現最佳的 GPT-4 Turbo，比例仍達 3.59%。

你可以選用自己最喜歡的模型。以團隊產生程式碼的規模計算，即使採用表現最佳的模型，這種情況每週仍會發生一次。

2026 年檢測：情況較少，問題未解

2026 年 5 月，一位獨立研究人員以相同方法測試了五個於 2025 年 10 月至 2026 年 3 月推出的前沿模型，並以 199,845 個提示詞進行測試，再對照 PyPI 和 npm 的完整套件清單核實結果。

幻覺率介乎 4.62% 至 6.10%。最佳與最差模型之間的差距，從大約十倍收窄至幾乎沒有。表面看來，這代表有所進步。

但還有一點：五個模型都以相同方式虛構的 127 個套件名稱。

這些名稱並非相似，而是完全相同；生成它們的模型來自不同公司，也經過不同的訓練。向 PyPI Security 作出協調披露後，當中仍有 53 個名稱可由任何人註冊，只需有帳戶和幾分鐘時間。

五個互相獨立的模型都認同同一個虛構名稱，代表攻擊者不必預測某個模型的特殊習慣。只需註冊這個共同的幻覺名稱，生態系統中的每個助手都會把用戶導向該名稱。

有人花 $496 發動了攻擊

2026 年，一個研究團隊做了大家都以為遲早會有人做的事。他們從八個知名 LLM 中找出 107 個虛構的套件名稱，將它們上載至 npm，並觀察了六個月。

整個行動估計只花了$496。

安裝中有 35.2% 來自真實開發者，而且大多數首次互動都在註冊後兩週內發生。另有 25.2% 的虛構名稱與真實套件名稱只差一個字元，即使有人查看，也近似得足以瞞過匆匆一瞥。

還有一項值得細想的發現：在生成器中加入網頁搜尋，反而令情況惡化。幻覺延續率由 11.2% 升至 17.3%，因為搜尋結果本身已受到 AI 生成內容污染。我們為減少幻覺而加入的工具，可能會悄悄替幻覺內容洗白。

為何 Agent 會令滋擾演變成攻擊途徑

人類輸入 pip install 時，通常會瞄一眼名稱。通常而已。Agent 不會瞄一眼。它會在執行任務時解析依賴項、安裝套件，然後回報成功。

故障模式由「我察覺到的惱人錯誤」，變成「我從未看見的依賴項」。

Cloud Security Alliance 在 2026 年 4 月不再含糊其詞：將每個由 AI 建議的依賴項都視為不可信輸入。這不是建議，也不是捷徑，而是來自一個有幾個百分點機會出錯、卻表現得信心十足的來源的輸入；真正的攻擊者已開始註冊名稱，伺機利用這一點。

堵住這條路的四項檢查

這些防禦措施都不複雜。CSA 的指引可歸納為四項檢查：

1. 安裝前先核實。 套件是否存在於套件登錄庫？它是否在你的專案開始前已經註冊？發布者是否有過往紀錄，還是這個名稱上個月才被人註冊？

2. 把鎖定檔當作關鍵基礎。 將它們提交至版本控制、安裝時核實雜湊值，並根據核准的鎖定檔建置，而不是跟着 Agent 的一時興起行事。

3. 為 Agent 設定允許清單。 如果你的編碼 Agent 可以安裝套件，就只讓它從人手核准的清單安裝。其他所有情況都要升級處理。

4. 產生 SBOM。 如果你的程式碼和依賴項有很大部分是透過生成而來，就需要一份清單，列明建置中實際包含的內容。

第一項檢查簡單得足以在 CI 中執行：

# the model suggests; the registry decides
import sys
import requests

REGISTRY = "https://pypi.org/pypi"

def exists(name: str) -> bool:
    return requests.get(f"{REGISTRY}/{name}/json", timeout=10).status_code == 200

suggested = ["requests", "fastapi", "pydantic", "strutils-pro"]  # from the agent
for pkg in suggested:
    if not exists(pkg):
        sys.exit(f"blocked: '{pkg}' is not on PyPI, a human looks at this one")

💡 專業提示： 虛構的套件如果無法安裝，代表系統正常運作。真正危險的是成功安裝的虛構套件，因為有人註冊該名稱的那一刻，它就不再只是虛構。

令我揮之不去的一點

比起 19.7%，我更常想到那 127 個重複出現的名稱。

比率告訴你模型多常出錯；重複出現的名稱則説明，這些失誤並非隨機。不同公司、不同訓練數據，卻得出同一個虛構套件。這是整個生態系統的特性，而非任何一家供應商的問題。轉用其他模型無法解決；怪責供應商就更無濟於事。

二十年來，供應鏈攻擊都需要有人打錯字、按下連結，或略過檢查。如今，錯誤名稱會在模型內以機器速度出現，而且出現機會達幾個百分點；至於按下連結，已非必要。

你有沒有發現助理建議了不存在的套件？你有核實嗎，還是由安裝失敗替你完成核實？

參考資料

Churilov，範圍收窄，威脅依然：重新評估 2026 年前沿模型羣組中的 LLM 套件幻覺（2026）：arxiv.org/abs/2605.17062
Huang 等人，套件幻覺：開源軟件供應鏈中的幽靈，ACM TOSEM（2026）：dl.acm.org/doi/abs/10.1145/3830237
Cloud Security Alliance，Slopsquatting：AI 程式碼幻覺助長供應鏈攻擊（2026 年 4 月）：labs.cloudsecurityalliance.org。CSA 的説明記錄了上述採用的 USENIX Security 2025 測量結果，以及完整的緩解措施指引。