你剛剛用 npm install 裝了一個密碼管理工具，它表面上安全無虞，實際上卻在你背後偷走你的 GitHub token、AWS 金鑰，甚至滲透你的 shell 設定檔。

這不是科幻情節。這是 Socket 安全研究團隊在 2026 年 4 月 23 日揭露的 Bitwarden CLI 供應鏈攻擊事件。

事件始末

Bitwarden 是全世界最受歡迎的開源密碼管理器之一，服務超過 1,000 萬名用戶和 5 萬家企業，在企業採用率上排名前三。它的 CLI 版本（命令列介面）讓開發者能在終端機中管理密碼、金鑰和敏感資訊，是許多 DevOps 工程師和系統管理員的日常工具。

2026 年 4 月 23 日，Socket 研究團隊發現 Bitwarden CLI 的 npm 套件 @bitwarden/cli@2026.4.0 被植入了惡意程式碼。

攻擊者利用 Bitwarden CI/CD 管線中的一個 GitHub Action 作為突破口，將惡意負載塞進 bw1.js 這個檔案中，隨著正常的版本發布流程一同發布到 npm 註冊表。任何在這段期間執行 npm install @bitwarden/cli 的開發者，都可能已經不知不覺地安裝了這個被污染的版本。

根據 Socket 的分析，這起攻擊與先前揭露的 Checkmarx 供應鏈攻擊事件（2026 年 4 月 22 日）使用相同的基礎設施和攻擊手法。換句話說，這不是一個孤立事件，而是一場大規模供應鏈攻擊的其中一環。

技術拆解：這波攻擊到底做了什麼？

Socket 的安全研究團隊對 bw1.js 進行了深入分析，發現了一系列精心設計的惡意行為。來看看攻擊者到底在你機器上做了什麼。

相同的 C2 基礎設施

bw1.js 使用的命令與控制（C2）端點與 Checkmarx 事件的 mcpAddon.js 完全相同：

嵌入式多重負載

bw1.js 包含了多層惡意負載，以 gzip 壓縮後再以 base64 編碼的方式嵌入：

  1. Python 記憶體掃描腳本：專門針對 GitHub Actions Runner.Worker 進行記憶體掃描，竊取執行中的 token
  2. setup.mjs loader：用於重新發布被污染的 npm 套件
  3. GitHub Actions 工作流程 YAML：注入到受害者的儲存庫中，竊取 repository secrets
  4. 硬編碼 RSA 公鑰：用於加密外洩的資料
  5. 意識形態宣言字串：一段關於「反機器抵抗」的宣言

憑證收割：不留死角

攻擊者建立了一份完整的憑證收割清單，幾乎覆蓋了所有開發者可能使用的認證方式：

這些憑證被加密後，透過 GitHub API 外洩到受害者帳號下新建的公開儲存庫中。這些儲存庫使用 Dune 主題命名（{單字}-{單字}-{3位數字}），並在 commit message 中嵌入 token，同時加上標記字串 LongLiveTheResistanceAgainstMachines。

供應鏈擴散機制

攻擊者不只滿足於單一機器的入侵。他們設計了一套供應鏈擴散機制：

  1. npm token 盜用：找出受害者有權限寫入的 npm 套件
  2. 重新發布：將惡意的 preinstall hook 注入這些套件
  3. GitHub Actions 注入：修改工作流程以竊取 repository secrets

這意味著，一旦你的開發環境被入侵，攻擊者可以利用你的權限，將惡意程式碼散播到你維護的所有套件中，進而感染更多下游使用者。

俄語環境迴避機制

這段惡意程式碼內建了「俄羅斯 kill switch」：如果系統語言設定以 “ru” 開頭（俄語），程式會靜默退出，不執行任何惡意行為。它透過 Intl.DateTimeFormat().resolvedOptions().locale 和環境變數 LC_ALL、LC_MESSAGES、LANGUAGE、LANG 進行檢查。

這種機制在惡意軟體中相當常見。它既可能是為了避免在俄語系國家的執法機構留下痕跡，也可能是攻擊者不想「誤傷」自己人。

新發現的行為特徵

與先前的 Checkmarx 事件相比，這波攻擊還多了幾個值得注意的新特徵：

這不是單一事件：Checkmarx 供應鏈攻擊的更大圖景

如果你覺得這一切聽起來很熟悉，那是因為你可能是對的。這起 Bitwarden CLI 攻擊是 Checkmarx 供應鏈攻擊的一部分。

所謂供應鏈攻擊，不是直接攻擊你的系統，而是攻擊你依賴的工具、套件或服務。就像毒販不會直接找你交易，而是在你常去的餐廳下毒——你怎麼死的都不知道。

根據 Socket 的調查，Checkmarx 攻擊事件的主要特徵包括：

  1. 攻擊入口：透過受感染的 GitHub Action 進入 CI/CD 管線
  2. 攻擊目標：npm 生態系中的開源套件
  3. 資料外洩：竊取開發者憑證、token 和 secrets
  4. 持續擴散：利用竊取到的權限感染更多套件

攻擊者在 Checkmarx 事件中假冒 Checkmarx 公司的身份，創建了看似合法的 GitHub Action，誘使開發者將其整合到 CI/CD 工作流程中。一旦被採用，這個 Action 就會在 CI/CD 環境中竊取 secrets 和 token。

Bitwarden CLI 的攻擊可視為同一個攻擊者（或攻擊集團）的延伸行動。兩種惡意軟體共享相同的 C2 基礎設施、編碼混淆技術和負載解壓結構，但在操作簽名上有所不同。

為什麼這是每一個開發者的問題

你可能會想：「我又不用 Bitwarden CLI，關我什麼事？」

這種想法很危險。這次事件的本質不是 Bitwarden 的問題，而是整個 npm 生態系和 open source 供應鏈的結構性弱點。

具體來說：

信任模型過於樂觀

當你執行 npm install 時，你相信 npm 上發布的套件是安全的。但實際上，npm 套件的發布機制依賴 token 認證，而這些 token 往往躺在你的 .npmrc 檔案或環境變數中，對攻擊者來說唾手可得。

CI/CD 是新的攻擊面

GitHub Actions 讓開發者可以輕鬆地自動化測試、部署流程。但每一個你整合到工作流程中的 Action，都是一個潛在的攻擊點。如果某個 Action 的維護者的帳號被入侵，或 Action 本身的發布流程被破壞，你的整個 CI/CD 管線就可能被污染。

開源維護者的困境

Bitwarden 是大型開源專案，有專職的安全團隊。如果連他們的 CI/CD 管線都能被攻破，那些由一兩個志願者維護的小套件，安全性就更難保證了。

你可以怎麼保護自己

雖然供應鏈攻擊看起來很嚇人，但有一些實務做法可以大幅降低風險：

1. 定期審查 CI/CD 管線

檢查你使用的每一個 GitHub Action，特別是那些來自第三方開發者的。問自己三個問題：
– 這個 Action 真的需要這麼多權限嗎？
– 它的原始程式碼有沒有被 review 過？
– 它的維護者是否活躍？

如果可能，鎖定 Action 的版本（使用 SHA commit hash）而不是浮動標籤。

2. 限制 npm token 權限

不要使用全域 npm token。為每個 CI/CD 環境建立專用 token，並將權限限制到最低。定期輪換 token，特別是在懷疑有安全事件發生時。

3. 使用依賴項掃描工具

Socket、Snyk、Dependabot 等工具可以幫助你自動掃描依賴項中的已知漏洞和惡意行為。根據 Socket 自身的研究，傳統的軟體組成分析（SCA）工具只能識別約 30% 的新型態供應鏈攻擊。

4. 隔離開發環境

考慮在容器或虛擬機器中進行套件安裝和測試。這樣就算套件被入侵，攻擊者也難以滲透到你的主要開發環境。

5. 實施最小權限原則

你的 CI/CD token 不應該有寫入生產環境的權限。你的 npm token 不應該有發布所有套件的權限。你的 GitHub token 不應該有存取私人儲存庫的權限。把權限切成最小單位，即使某個環節被突破，損害也能被控制在有限範圍內。

6. 如果你已經使用了受影響的版本

Socket 團隊建議，如果你在 2026 年 4 月 23 日前後執行了 Bitwarden CLI 的更新：

更深層的問題：開源安全誰來負責？

回到這次事件的本質，我們不得不面對一個尷尬的事實：開源軟體的安全性長期被低估。

開源軟體是現代網際網路的基石。你的手機、你的伺服器、你的雲端服務，都依賴於成千上萬個開源套件。但這些套件中的大多數由志願者維護，安全審查的覆蓋率遠遠不足。

Bitwarden 是幸運的——它有商業支援，有專業的安全團隊，被攻擊後能迅速被發現並回應。但如果攻擊的目標是一個只有幾百次下載的小套件呢？誰來發現？誰來通報？誰來修復？

這不是危言聳聽。根據 Sonatype 的年度供應鏈攻擊報告，過去三年間，軟體供應鏈攻擊的發生次數大幅增加。攻擊者越來越意識到，直接攻擊大型企業的難度很高，但透過污染它們依賴的開源套件，可以以極低的成本達到同樣的效果。

觀察者的視角

供應鏈攻擊並不是什麼新鮮事。從 2020 年的 SolarWinds 事件，到 2024 年的 XZ Utils 後門事件，再到這次的 Bitwarden/Checkmarx 攻擊，模式越來越清晰——攻擊者不再直接敲你家的大門，而是找到供應你建材的工廠下毒。

這次事件最讓我警覺的不是技術細節有多精巧，而是攻擊者的「投資報酬率」。一個小隊的攻擊者，花幾個月的時間開發一個看起來合法的 GitHub Action，然後等待它被整合到某個大型專案的 CI/CD 管線中。一旦成功，他們就能輕易獲得成千上萬個開發者的憑證。這比逐個攻擊目標有效率太多了。

對於台灣的開發社群來說，我認為有一個特別值得關注的面向——我們的開源生態系相對較小，但許多企業的核心系統已經高度依賴 npm、PyPI、Docker Hub 等大型套件倉庫。當這些平台上的某個套件被污染時，影響往往不分國界。

說到底，安全不是一個產品，不是一個工具，不是一次性的審計。它是一個持續的過程，是每一次 npm install 前的那一秒猶豫，是每一次權限設定時多想一步的謹慎。沒有人能 100% 不被攻擊，但我們可以做到讓自己不是那個最容易下手的目標。

保持警覺，定期審查，不隨便信任——在供應鏈攻擊越來越頻繁的時代，這三件事比任何安全工具都重要。