實際事件 發布於 AIA: 2026年5月8日

PromptMink：惡意套件如何騙開發 agent 把自己加進專案

ReversingLabs 將 PromptMink 歸因於具北韓背景的攻擊組織 Famous Chollima；攻擊者先用看起來可信的 npm / PyPI 套件和精心設計的說明文件，吸引開發者或 agent 採用；真正有害的程式碼則放在另一個可以替換的相依套件裡，藉此打進 AI 輔助開發流程。其中一個自主加密貨幣交易 agent，在一個標示 Claude Opus（Anthropic 的模型）參與產生的 commit 裡加入了惡意套件。真正的防禦重點是：AI coding agent 選套件時，不能把它當成只是替專案多加一個外掛或套件；這其實是一次軟體供應鏈決策，套件來源、版本和相依關係都要先審查。

Malicious PackagesSupply Chain CompromisePackage VettingAI Supply ChainAI Coding Agent
9 項對應的 AIDEFEND 防禦手法
來源: Claude adds malware to crypto agent 
作者: Vladimir Pezo, ReversingLabs
原文發布: 2026年4月29日

威脅分析

  • 攻擊步驟先看全貌。 攻擊者先做出看起來正常的 npm / PyPI 誘餌套件，README 和功能描述也寫得像真的能解決加密貨幣、驗證或資料處理需求。開發者或 coding agent 採用後，這個套件再拉進第二層相依套件；真正的竊資程式碼藏在第二層。
  • 第二層可以替換，外層誘餌就能繼續留著。 第一層誘餌套件，例如 @solana-launchpad/sdk，表面上提供正常功能，也能累積下載紀錄和歷史可信度；第二層套件，例如 @validate-sdk/v2，才放真正的竊資功能。就算第二層惡意套件從 npm / PyPI 被下架，攻擊者也可以讓第一層誘餌改去引用新的惡意套件；外層看起來仍像原本那個正常工具。
  • 竊資程式換過好幾種形式。 PromptMink 一開始是經過混淆的 JavaScript 竊資程式；後來又出現 PyPI 套件版本、打包成 Node 執行檔的版本，以及用 Rust 寫成的 NAPI add-on（Node.js 可載入的原生擴充模組）。後期版本能收集 .env 和 .json 檔、壓縮並外傳整個專案原始碼，還能加入攻擊者的 SSH key 來維持後續存取。
  • AI 輔助工作流程變成新的入口。 ReversingLabs 找到一個自主加密貨幣交易專案，其中惡意相依套件是在 2026 年 2 月 28 日的一個 commit 裡加進去；該 commit 記錄標示 Claude Opus 也參與產生。問題不是模型自己寫了惡意程式，而是 agent 把一個看起來合理的相依套件帶進了真實程式碼庫。
  • 模型幻想出的套件名稱，會讓同一類攻擊更容易發生。 相關的幻覺套件搶註（slopsquatting，假設 agent 想找 Solana 錢包驗證工具，編出像 solana-wallet-validator 這種看起來合理、但 registry 原本沒有的套件名；攻擊者先把這個名字註冊到 npm 或 PyPI）風險在於：agent 之後可能用 npx、npm、pip 或其他套件管理工具，把攻擊者註冊好的惡意套件裝進來。
  • 防線要放在套件進專案之前。 套件被寫進套件清單檔（manifest，例如 package.json）或版本鎖定檔（lockfile）以前，就要先查來源、維護者、版本和相依關係；真的要安裝或測試時，也要放在隔離環境裡跑。只審最後產生的程式碼，會錯過惡意相依套件第一次被下載、安裝或執行的時刻。

適用的 9 項 AIDEFEND 防禦手法

AID-H-022.002
Pre-Merge Dependency Change Risk Review
極高
PromptMink 利用的正是看起來可信、又可能由 agent 提議的相依套件變更。這類 pull request 合併前，必須針對確切套件、版本、來源與 lockfile 差異，檢查漏洞、授權條款、維護者與來源儲存庫信譽、版本來源、安裝腳本差異，以及套件名稱是否有錯字或相似字元。分析結果缺漏或無法取得，都不能放行。這項控制負責擋下原始碼變更；實際套件檔案的惡意程式掃描與最終建置核准，仍是另外兩道控制。
AID-H-031.002
Static Admission Gates for AI-Generated Artifacts
極高
這次被觀察到的入侵點，是 AI 輔助產生的相依套件變更。合併或建置前的靜態檢查，應該把 AI 產生或 AI 實質修改過的 manifest、lockfile、build script 和 import 變更，都視為較高風險變更；只要看到未核准套件、套件會再拉進來的可疑相依套件、幻想套件名稱、安裝 script、打包二進位檔，或新加入的讀取憑證程式碼，就預設擋下。
AID-H-022.001
Sandboxed Dependency Installation
高
PromptMink 的惡意程式會偷環境檔、壓縮專案原始碼，甚至加入 SSH key。相依套件安裝應該放在一次性的沙箱環境（sandbox）裡執行：裡面不要有長效 secrets、不要有 SSH key，也不要把開發者的 home directory 掛進去；安裝時會自動跑的 script（例如 npm postinstall）要預設停用，並嚴格限制對外連線。這樣就算 agent 選錯套件，傷害也比較不會波及開發者的本機環境或 CI 主機。
AID-H-003.001
Software Dependency & Package Security
高
PromptMink 是很直接的 AI 軟體供應鏈攻擊。相依套件安全控制應該固定版本和雜湊、要求 lockfile 審查、掃描 npm 與 PyPI 套件是否含惡意程式或可疑二進位檔、驗證來源 repo，並阻止套件再拉進來的不可信相依套件進入 AI 產生或 AI 輔助的開發流程。
AID-H-031.004
Evidence-Bound Promotion & High-Risk Human Approval
高
替 crypto trading agent 新增相依套件，不是低風險小改，尤其當這個變更是 AI agent 提議，或 commit 記錄標示 AI 參與產生時。決定是否讓這個變更進入下一階段時，應該綁定證據：精確套件名稱與版本、相依套件樹、registry 中繼資料（metadata）、惡意程式掃描結果、審查者身分，以及這次要合併或發布的建置成品雜湊值（artifact digest）。高風險相依套件變更要有具名核准，才能 merge 或 release。
AID-I-001.004
Sandbox Network Egress Restrictions
高
PromptMink 後期版本會把 secrets 和專案原始碼傳到攻擊者控制的伺服器。agent 的建置沙箱、相依套件安裝工作和測試執行環境，都應該採用預設拒絕對外連線，只允許必要 registry 或內部服務；就算惡意程式碼真的執行，也比較難偷走憑證、把專案傳出去。
AID-M-009.002
Authority Envelope & Action Risk Classification
中
coding agent 讀程式碼，和它新增相依套件、跑 npx、改 lockfile、執行套件安裝 script，是不同風險等級的動作，不能都用同一套自動放行規則。把套件安裝、相依套件變更和 build script 執行歸類為高風險動作，系統在執行時才有政策依據要求人工核准、限制工具，或直接拒絕。
AID-M-001.002
AI System Dependency Mapping
中
一旦確認某個 PromptMink 套件或攻擊者控制網域，防禦方不能只停在「知道這是 IOC」。相依關係盤點要回答的是：哪些 repo、lockfile、CI cache、容器、notebook、agent 和開發者機器裡出現過它；這份清單會決定哪些地方要隔離、哪些 secrets 要輪替、哪些紀錄要回查。
AID-E-003.003
Confirmed Malicious Code & Persistence Eviction
中
PromptMink 不只是裝一個套件就結束。有些版本會加入 SSH key、偷環境檔，並留下攻擊者可用的存取路徑。事件應變時要移除惡意套件與 lockfile 項目、刪掉未授權 SSH key，也要檢查 cron、工作排程或啟動項裡有沒有被加入會讓惡意程式之後再跑的設定；接著輪替可能外洩的 secrets，並檢查專案封存檔與對外連線紀錄，確認是否已經發生外傳。

身為資安防禦者，我們應該這麼做

  • 在 source repo、lockfile、package manifest、CI cache、開發者機器和 artifact registry 裡搜尋 PromptMink 指標，包括惡意套件 @validate-sdk/v2、@hash-validator/v2、@solana-launchpad/sdk、PyPI 套件 scraper-npm，以及已知 C2（command-and-control，攻擊者用來接收外傳資料或下指令的控制伺服器）網域，例如 validator[.]uno。
  • 要求 AI coding agent 在新增任何 npm、PyPI、Rust 或 GitHub 相依套件前，先查套件信譽和惡意程式判定。不能只因為 README 看起來剛好相關，就讓 agent 直接安裝。
  • agent 產生的相依套件變更，除非已檢查精確套件版本、lockfile diff、它會直接或間接拉進來的相依套件、registry 上架時間、維護者歷史，以及套件裡是否含可疑二進位檔或原生模組，否則預設擋下或送人工審查。
  • 把套件安裝和測試放進一次性的沙箱環境（sandbox）：裡面不要有正式環境 secrets、SSH key，也不要把開發者的 home directory 掛進去；安裝時會自動跑的 script（例如 npm postinstall）預設停用；對外連線只允許到核准過的 registry。
  • 偵測套件安裝後的不正常行為：新增的 SSH authorized keys、非預期專案 ZIP 檔、讀取 .env 或錢包相關檔案、連到陌生網域，以及從開發機或 CI 主機送出的大量資料。
  • 把幻想套件名稱也納入控制。如果 agent 提議的套件不存在於已核准 registry 或內部 allowlist，就預設失敗，必須先經人工審查才能安裝。

1 個額外的防禦考量

套件文件對 agent 的誘導風險

除了上面對應的防禦技術，使用 AI coding agent 的開發與資安團隊，也應該把套件說明文件、README、範例程式和 registry 描述，視為會影響 AI coding agent 判斷的攻擊面。PromptMink 顯示，攻擊者可以把文件寫得像剛好符合開發任務，讓 agent 更容易選到它；等傳統惡意程式分析開始時，套件可能已經被加入專案。
建議做法: 審查套件時，不只看程式碼，也要看文件是否刻意影響 agent 的選擇：例如過度堆疊關鍵字、沒有證據支持的功能宣稱、看起來像捏造出來的基準測試說法，或文件承諾和實際程式行為對不上。這些跡象應該成為是否允許 agent 加入套件、或是否送人工審查的判斷依據。

結論

PromptMink 很清楚地說明，AI 輔助開發正在改變軟體供應鏈風險。攻擊者不一定要直接攻擊模型本身；只要讓惡意相依套件看起來像 agent 當下開發任務最適合的選擇，就可能被錯誤地拉進真實專案。AIDEFEND  在這裡對應到最重要的防禦手段和觀念：選套件前先審查、AI 產生的相依套件變更在進入專案前要先檢查、安裝過程要隔離、對外連線要限制、套件安裝要被歸類成高風險 agent 動作、相依關係要盤清楚，找到惡意套件後也要快速清掉後續存取路徑與外洩痕跡。