適合誰讀：使用 npm 或 pnpm 開發、把程式碼放在 GitHub、或從 CI 部署的人。本文根據廠商和研究機構公開的研究撰寫，不含攻擊步驟或樣本。
發生了什麼（ChainDrop，2026 年 8 月）
2026 年 8 月 4 日
維護多個廣泛使用的快取套件的維護者 GitHub 帳號遭入侵。攻擊者觸發這些專案既有的 GitHub Actions 發布工作流程，把被污染的版本發布到 npm。四小時內
444 個套件、2,212 個版本遭污染，其中包括每週合計下載量超過 5 億次的套件。安裝時
安裝時的掛鉤收集了 npm、GitHub、雲端（AWS/GCP/Azure）、SSH 金鑰、Kubernetes 和 CI/CD 的認證資訊。根據公開分析，還包括從 CI runner 記憶體中擷取的短效 OIDC 權杖。之後
攻擊者用偷來的認證資訊，重新發布受害者有權發布的所有套件（自我擴散），並把收集到的機密資訊外傳到攻擊者建立的公開 GitHub 儲存庫。
這一類攻擊的主要損害：私有儲存庫被公開
Shai-Hulud 系列蠕蟲會用偷來的 GitHub 權杖，把受害者的私有儲存庫複製成公開儲存庫，已有報告指出名稱以 -migration 結尾。GitHub 並沒有被攻破。從你的筆電或 CI runner 偷走的權杖，是以你自己的權限，把這件事當作正常操作來執行。所以「等平台修正」在這裡不是防禦手段。
為什麼沒有被擋下
加入相依套件／在 CI 中安裝
↓ preinstall / postinstall 自動執行
在你的電腦或 runner 上執行任意程式碼
↓ 收集 npm / GitHub / 雲端 / SSH / CI 機密資訊
用偷來的權杖執行正常操作
私有儲存庫被複製成公開／重新發布套件以擴散
沒有幫上忙的
- 簽章與來源證明：以維護者權限合法簽發，所以驗證會通過
- 「這是很熱門的大套件」：被污染的正是這種套件
- 只靠固定版本：全新安裝或下次升版時仍會拉到
- 等平台修正：被利用的是有效的權杖和公開的 API
有幫助的
- 預設停用安裝腳本：程式碼根本不會執行
- 採用新版本前設冷卻期：避開從發布到下架之間的期間
- 短效、範圍最小的權杖：限制被偷走的權杖能做什麼、能用多久
- 限制 CI runner 的對外連線：封住外傳的路徑
今天就做的五件事
搜尋自己的 lockfile
檢查是否含有已通報遭污染的版本（例如 keyv@6.0.0、flat-cache@6.1.24、file-entry-cache@11.1.6）。沒有找到是好消息，但第 2 步之後是為下一次類似攻擊做準備，請繼續做下去。
預設關閉安裝腳本
讓 CI 使用 npm ci --ignore-scripts；pnpm 則在 .npmrc 設定 ignore-scripts=true，只明確允許真的需要建置的相依套件。這是效益最高的單一改動，因為它拿掉了這種攻擊所依賴的執行階段。
新版本發布後等幾天再採用
不要在版本一發布就採用，3 到 7 天的冷卻期就夠了。像這次一樣，從發布到下架只有幾小時到幾天時，光是等待就能避開。如果使用自動更新 PR，請把這段延遲寫進設定。
2026-09-05 補充：這已經不必靠紀律來維持。Node.js 官方安全指南在供應鏈攻擊的緩解措施中，列出了用 --min-release-age（npm v11.10.0 以上）設定相依套件冷卻期，避免安裝剛發布的套件。**能用設定解決的，就不要靠紀律。**依賴有人記得的程序，在忙碌的日子很容易被跳過。
盤點權杖，縮短期限並縮小範圍
把 GitHub 個人存取權杖從 classic 換成 fine-grained，縮短期限，並只限於需要的儲存庫。不要把 npm 發布權杖一直放在 CI 裡。金鑰與機密資訊的處理方式，請見 .env 與 API 金鑰的危險之處和 SSH 金鑰的最小權限。目標是讓被偷走的權杖造成的損害很小。
檢查自己的 GitHub 帳號
找找看有沒有不是你建立的公開儲存庫（名稱以 -migration 結尾、陌生的說明）、你沒加過的 GitHub Actions 工作流程、被放進 .vscode/tasks.json 或 .claude/ 的可執行設定，以及你不認得的 API 金鑰或 SSH 金鑰。要用機器持續監看相依套件中的已知漏洞，請見 osv-scanner 入門。
懷疑遭感染時，順序要對
研究人員特別強調一點：先移除留在電腦上的常駐元件（監看權杖的腳本等），再撤銷權杖。順序顛倒的話，常駐元件可能會對撤銷做出反應。大致步驟：
1. 中斷網路連線
2. 移除常駐機制與可疑檔案
3. 依 npm → GitHub → 雲端 → SSH → Kubernetes 的順序撤銷並重新簽發
4. 刪除 node_modules 與快取，乾淨地重新安裝
5. 檢查公開儲存庫和套件發布紀錄
沒有日誌時，答案是「不知道」，而不是「沒事」。請當作已遭入侵來處理。
本站的看法：簽章證明的是來源，不是安全
簽章與來源證明多年來一直是供應鏈安全的首要建議，而這次攻擊繞過了它們。這並不意外：簽章告訴你誰發布了它，而不是它的內容是否安全。被入侵帳號簽出的有效簽章，同時是有效的，也是危險的。所以我們不把來源證明當作讓你安全的控制措施，而是當作事後界定影響範圍的鑑識工具。預防取決於另外兩件事：不要在安裝時執行別人的程式碼，也不要把機密資訊放在那段程式碼會執行的地方。
資料來源
- Unit 42（Palo Alto Networks）— ChainDrop: Inside a Self-Propagating npm Worm（擴散方式、被收集的認證資訊、入侵指標）
- StepSecurity — ChainDrop npm Worm（偵測指標與處置順序）
- Elastic Security Labs — CHAINDROP worm hits 400+ npm packages
- Node.js「Security Best Practices」— nodejs.org（供應鏈攻擊的途徑與緩解措施：
--ignore-scripts、lockfile、npm ci，以及--min-release-age冷卻期；2026 年 9 月 5 日確認） - SecurityWeek — Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack（規模與經過）
- Wiz — Shai-Hulud npm Supply Chain Attack（把私有儲存庫複製成公開的手法）
接著讀
- 2026 年的案例：TanStack、Nx Console 與 GitHub 的連鎖事件：開發者該檢查什麼（英文）
- 實作：用 osv-scanner 機器監看相依套件的 CVE／用 gitleaks 在提交時擋下機密資訊
- 基礎：.env 與 API 金鑰的危險之處／SSH 金鑰的最小權限
- 比較：自架 Git 與 GitHub，哪個比較安全
- 經由相依套件進來的缺陷：Node.js 的原型污染（即使合併函式是相依套件寫的，也算在內）
- 用語：什麼是惡意軟體
- 同樣的模式：2026 年的入侵多半透過有效的認證資訊（英文；同樣是被偷的權杖執行一般操作）
FAQ
Q為什麼執行 npm install 就可能被偷走認證資訊？
因為套件可以帶有在安裝時自動執行的腳本（preinstall／postinstall）。加入相依套件，就等於讓那段程式碼以你的權限執行。ChainDrop 正是利用這一點，收集了 npm、GitHub、雲端、SSH 和 CI/CD 的認證資訊。
Q「私有儲存庫被公開」是什麼意思？
這一類蠕蟲會用偷來的 GitHub 權杖，把受害者的私有儲存庫複製成公開儲存庫，已有報告指出名稱以 -migration 結尾。GitHub 本身並沒有被攻破：從你的電腦或 CI 偷走的權杖，是以你自己的權限執行這個操作。所以等平台修正並不能保護你。
Q有簽章、有來源證明的套件不就安全了嗎？
這次被繞過的正是這一點。攻擊者用維護者的權限觸發了專案既有的發布工作流程，所以被污染的版本帶著有效的來源證明發布。簽章證明的是誰發布的，不是內容是否安全。被入侵帳號簽出的有效簽章，仍然是有效簽章。
Q今天最有效的一件事是什麼？
兩件事：預設停用安裝腳本（npm ci --ignore-scripts，pnpm 則設定 ignore-scripts=true），以及不要在新版本一發布就立刻採用，先等幾天。前者讓程式碼根本不會執行；後者避開最危險的期間，也就是從發布到下架之間的幾小時到幾天。