部落格發布於 AIA: 2026年5月8日

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

ReversingLabs 將 PromptMink 歸因於具北韓背景的攻擊組織 Famous Chollima；攻擊者先用看起來可信的 npm / PyPI 套件和精心設計的說明文件，吸引開發者或 agent 採用；真正有害的程式碼則放在另一個可以替換的相依套件裡，藉此打進 AI 輔助開發流程。其中一個自主加密貨幣交易 agent，在一個標示 Claude Opus 參與產生的 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-023.002

Proactive Package Vetting

極高

這是最直接的預防控制。PromptMink 靠的是看起來有用、可信、文件又寫得像真的套件；等到惡意相依套件真的執行，就已經太晚。套件信譽、維護者歷史、registry 上架時間、套件裡是否含可疑二進位檔或原生模組、它會再拉進哪些相依套件，以及已知惡意套件判定，都應該在 coding agent 工作流程裡先出現，不能等 agent 已經把 @solana-launchpad/sdk、@validate-sdk/v2 或相似套件加進專案後才補查。

AID-H-032.002

Static Admission Gates for AI-Generated Artifacts

極高

這次被觀察到的入侵點，是 AI 輔助產生的相依套件變更。合併或建置前的靜態檢查，應該把 AI 產生或 AI 實質修改過的 manifest、lockfile、build script 和 import 變更，都視為較高風險變更；只要看到未核准套件、套件會再拉進來的可疑相依套件、幻想套件名稱、安裝 script、打包二進位檔，或新加入的讀取憑證程式碼，就預設擋下。

AID-H-023.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-032.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

Malicious Code & Configuration Cleanup

中

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 動作、相依關係要盤清楚，找到惡意套件後也要快速清掉後續存取路徑與外洩痕跡。