在 2026 年 3 月 31 日，攻擊者入侵了 axios npm 套件主要維護者的帳號，並發布了兩個惡意版本。這些版本會在 macOS、Windows 及 Linux 系統上悄悄安裝跨平台的遠端存取木馬 (RAT)。Axios 是目前最廣泛使用的 JavaScript 函式庫之一，每週下載量高達約 1 億次，且有超過 17.4 萬個套件使用它。雖然這兩個帶毒的版本 (Poisoned versions) 上線時間不到三小時，但在這段期間內執行 npm install 的任何專案，都已被植入後門。此次事件並非 axios 本身程式碼的弱點 (Vulnerability)，因此不太可能獲得傳統的 CVE 編號。後續追蹤請參考 npm 安全通告 (Security Advisories) 及 GitHub 安全通告 (GHSA)。

事件快速總覽 (Quick Overview)

什麼是 Axios？

Axios 是一個基於 Promise 的 HTTP 用戶端 (HTTP Client) 函式庫，可用於 JavaScript 並同時支援 Node.js 與瀏覽器環境。如果你在過去十年內寫過 JavaScript，幾乎可以肯定你曾直接使用過它，或是使用的工具中依賴它。Axios 位處超過 17.4 萬個 npm 套件的相依性樹狀結構 (Dependency Tree) 之中；這類基礎函式庫 (Foundational libraries) 一旦遭到入侵，影響的將不只是直接使用者，更會產生連鎖反應 (Cascades)，波及下游無數的應用程式、CI/CD 流水線以及生產環境。

 Socket 的共同創辦人 Feross Aboukhadijeh 在 X (原 Twitter) 上發布了首個公開警報。隨後，StepSecurity 的研究員 Ashish Kurmi 開啟了 GitHub Issue #10604 以協調社群的應變行動，並提交了弱點報告。儘管如此，由於此次事件屬於供應鏈入侵 (Supply Chain Compromise) 而非程式碼本身的漏洞，因此不太可能獲得傳統的 CVE 編號。

技術分析

帳號如何遭入侵

此次攻擊始於 axios 主要維護者 jasonsaayman 的 npm 帳號遭接管 (Takeover)。攻擊者將帳號註冊的電子郵件更改為其控制的 ProtonMail 位址 (ifstap@proton.me)，隨後利用 npm CLI 直接發布了帶毒的套件 (Poisoned packages)。

這點至關重要，因為 axios 的正規版本發布是採用 npm 的「受信任發布 (Trusted Publishing)」機制。這套系統透過 GitHub Actions 與加密的 OIDC 權杖 (Tokens) 進行發布，將每一次發布與特定的 CI 工作流 (Workflow) 綁定，若沒有對應的程式碼變更，根本無法進行發布。而惡意版本則是透過手動發布，完全繞過了這道防線。最可能的入侵點是使用了長效型 (Long-lived) 的傳統 npm 存取權杖 (Access Token)，這類權杖不像受信任發布所使用的臨時 OIDC 權杖，它有時能完全規避二階段驗證 (2FA) 的要求。

數位鑑識 (Forensics) 的跡象非常明確：正版的 axios@1.14.0 顯示發布者為 GitHub Actions，並帶有 trustedPublisher 的 OIDC 證明 (Attestation)；然而惡意版本 axios@1.14.1 的發布者卻顯示為 jasonsaayman 及其 ProtonMail 位址，且完全沒有任何來源證明 (Provenance data)。在 axios 的 GitHub 儲存庫 (Repository) 中，也找不到任何對應的 Commit、Tag 或 Release 紀錄。

幽靈相依性詭計 (The Phantom Dependency Trick)

攻擊者完全沒有修改 axios 的任何 JavaScript 原始碼檔案。唯一變動的地方只有 package.json：他們在裡面新增了一個執行階段的相依性套件 plain-crypto-js@^4.2.1，並調升了版本號。經過對 axios@1.14.1 所有 86 個檔案的搜尋，確認在整個程式碼庫中，完全沒有任何地方使用了 import 或 require 來呼叫 plain-crypto-js。

它純粹以一個「幽靈相依性 (Phantom Dependency)」的形式存在，其唯一的目的是利用 postinstall Hook (這是 npm 在安裝完套件後會自動執行的腳本) 來觸發惡意的資料內容。攻擊者對此進行了精密的預先部署：在 axios 遭到入侵的大約 18 小時前，npm 用戶 nrwise (nrwise@proton.me) 先發布了一個乾淨的版本 plain-crypto-js@4.2.0。這個版本是合法 crypto-js 函式庫的完全副本，不含任何惡意程式碼，目的是為了累積發布紀錄，並規避那些會針對「全新套件」進行標記的啟發式偵測機制 (Detection Heuristics)。帶毒的 4.2.1 版本則在一天後隨之而來，加入了經過混淆的 Dropper 腳本 (setup.js) 以及負責執行它的 postinstall hook。

Dropper 下載器內部構造

這個名為 setup.js 的 Dropper (大小為 4,209 bytes) 採用了兩層編碼方案 (Two-layer encoding scheme) 來隱藏其真實意圖。所有敏感字串都儲存在一個編碼過的陣列中，並透過兩個鏈接函數 (Chained functions) 進行解碼。內層解碼：套用了 XOR 運算 (XOR Cipher)，這是一種常見於簡單混淆技術中的可逆位元運算，其使用的金鑰為 "OrDeR_7077"。由於 JavaScript 的 Number() 函數會將英文字母強制轉型為 NaN（在位元運算中會變為 0），因此實質上的有效金鑰會簡化為位元組序列 [0,0,0,0,0,0,7,0,7,7]。每個字元的解碼公式為：charCode XOR key[(7 * r * r) (mod 10)] XOR 333。外層解碼：將字串反轉、將底線 (_) 替換為等號 (=)、進行 Base64 解碼，最後再將結果送入上述的 XOR 層處理。

一旦解碼完成，該 Dropper 的運作架構便無所遁形：它會導入 (Import) child_process、os 和 fs 模組，藉此識別主機作業系統平台，並連線至位於 http://sfrclak.com:8000/6202033 的 C2 (中繼站) 伺服器，以抓取對應平台的 RAT (遠端存取木馬) 資料內容。

各平台特定的惡意資料內容 (Payload)

針對不同作業系統，此攻擊部署了三種不同的資料內容。以下是 macOS 部分的分析：

• macOS 平台：

Dropper 會在系統的暫存目錄 (Temp directory) 寫入一個 AppleScript 檔案，並透過 osascript 指令靜默執行。該腳本會連向 C2 伺服器 下載一個經編譯的 C++ RAT 二進位檔案，並將其儲存在： /Library/Caches/com.apple.act.mond 這個路徑是刻意選擇的，目的是為了模擬 Apple 系統服務 (System daemons) 常用的反向網域名稱 (Reverse-DNS) 命名慣例。隨後，該二進位檔案會被賦予 chmod 770 執行權限，並透過 /bin/zsh 啟動。根據 StepSecurity 的分析，該 RAT 每 60 秒會向 C2 伺服器發送一次 信標 (Beacon) 訊號，並支援執行 Shell 指令、檔案系統列舉 (Filesystem enumeration) 以及自我終止 (Self-termination) 等功能。

• Windows 平台：

Dropper 會先定位 PowerShell 執行檔，將其複製到 %PROGRAMDATA%\wt.exe（偽裝成 Windows Terminal），隨後在暫存目錄寫入一個 VBScript 檔案，並透過 cscript 執行。該 VBScript 會啟動一個隱藏的 cmd.exe，從 C2 伺服器下載一個以 PowerShell 為基礎的 RAT 腳本，儲存為 %TEMP%\6202033.ps1，最後以 -ExecutionPolicy Bypass -WindowStyle Hidden 參數執行（意即：繞過執行原則並隱藏視窗）。

• Linux 平台：

透過 Shell 指令將一個 Python 編寫的 RAT 腳本下載至 /tmp/ld.py，並利用 nohup python3 以分離模式（Detached）執行。根據 StepSecurity 的執行階段分析，確認該 Python 程序被刻意轉化為孤兒行程 (Orphaned process)，其 PID 1（即由 init 系統接管）。此手法有助於規避程序樹 (Process-tree) 的追蹤與歸因，並確保即使 npm install 的連線作業結束，該惡意程序仍能持續執行（Persist）。

所有三種平台的資料內容在與 C2 伺服器溝通時，其 POST Body 都會格式化為 packages.npm.org/product0、product1 或 product2。這種格式是一種刻意的偽裝 (Camouflage)，目的是讓對外的異常流量在網路監控工具中看起來像是正當的 npm registry 通訊。

反數位鑑識與證據銷毀

在啟動惡意資料內容 (Payload) 後，Dropper 會透過以下三個步驟進行自我清理，以湮滅證據：
1. 刪除 setup.js。
2. 刪除帶有犯罪證據的惡意 package.json（即包含惡意 postinstall 鉤子的檔案）。
3. 將預先準備好的乾淨資訊清單 (Manifest) 檔案 package.md 重新命名為 package.json。

這導致受害者在感染後的機器上，若去檢查 node_modules/plain-crypto-js/ 目錄，只會看到一個完全乾淨、沒有 scripts 區塊、且毫無 Dropper 痕跡的 package.json。此時執行 npm audit 也無法偵測到任何異常。根據 StepSecurity 的 Harden-Runner 偵測結果顯示，這種「掉包」行為發生得極快：惡意資訊清單寫入後，僅過了 36 秒，乾淨的替換檔案就出現了。

攻擊流程 (Attack Flow)

1. 攻擊者接管了 jasonsaayman 的 npm 帳號（極有可能是透過竊取的長效型存取權杖 - Long-lived Access Token）。
2. 攻擊者利用一個免洗的 npm 帳號，先發布了 plain-crypto-js@4.2.0（乾淨版本），接著發布 4.2.1（惡意版本）進行佈局。
3. 攻擊者發布 axios@1.14.1 與 axios@0.30.4，並在其中注入了對 plain-crypto-js 的相依性。
4. 任何執行 npm install 的專案，都會因為 Caret Range (^) 版本範圍設定而自動抓取到新的 axios 版本，並觸發 plain-crypto-js 的 postinstall 鉤子 (hook)。
5. postinstall 鉤子執行 setup.js，該腳本會進行解碼並啟動針對不同平台的 Dropper (下載器)。
6. Dropper 連向 C2 伺服器下載 RAT (遠端存取木馬)；在 npm install 完成後的 1.1 秒內，便已完成安裝並建立持久性存取 (Persistent access)。
7. Dropper 隨即銷毀所有自身的活動證據，並在原位留下一個乾淨的 package.json 檔案。

受影響版本清單 (Affected Versions)

所有受影響的版本都已從 npm 下架。 axioslatest的 dist 標籤目前指向 1.14.0 版本。

威脅狀態 (Threat Status)

攻擊活動 (Exploitation Activity)：已確認有實際攻擊發生。惡意版本在 npm 上存在了大約 2 至 3 小時。StepSecurity 透過 Harden-Runner 確認，首個與 C2 (中繼站) 的連線會在 npm install 完成後的 1.1 秒內觸發。此次入侵事件也在知名開發者入口框架 Backstage 儲存庫的 CI 執行過程中被獨立偵測到，證實了此攻擊已在現實世界的 生產流水線 (Production Pipelines) 中被執行。
概念驗證 (PoC) 可用性：在 npm 移除套件之前，Socket、StepSecurity 和 SafeDep 已捕獲並分析了惡意程式碼。目前網路上已有公開且詳細的技術拆解報告。在初始報告發布時，C2 伺服器網域 (sfrclak.com) 仍可解析。
歸因 (Attribution)：目前尚未正式歸因於任何已知的威脅組織。Socket 明確表示，沒有證據顯示此事件與近期報導的 TeamPCP 活動有關。資安社群注意到資料內容中並不包含挖礦程式或勒索軟體，而是專注於持續性的 C2 信標 (Beaconing)、系統偵測 (Reconnaissance)，以及針對 .ssh 和 .aws 目錄的攻擊。這種行為模式與專注於情報蒐集的 APT (進階持續性威脅) 組織較為一致，而非單純以金錢利益為動機的犯罪；不過，這目前仍屬於推測階段。

事件重要性分析 (Why This Matters)

此次事件的立即影響範圍極其廣大。在 npm 的預設版本語法下，任何對 axios 使用 Caret Range (^) 相依性設定（例如 ^1.14.0 代表「接受到下一個大版本前的任何相容版本」）的專案，只要在那大約三小時的空窗期內執行了 npm install，就會自動抓取到受污染的版本。考量到 axios 每週高達 1 億次的下載量以及超過 17.4 萬個依賴套件，即使是極短的暴露時間，也足以轉化為巨大的潛在衝擊。無論是排程執行的 CI/CD 流水線、早上剛開工的開發人員，還是自動化部署作業，任何在這段時間內執行過 npm install 的行為，都極可能已經遭到入侵。

令整個生態系感到擔憂的是：axios 其實已經採用了 npm 的「受信任發布 (Trusted Publishing)」機制。理論上，這套機制透過將發布流程與可驗證的 CI 工作流綁定，應該能完全防止這類攻擊。然而，維護者的帳號中仍保留了傳統長效型 (Classic Long-lived) 的 npm 權仗 (Token)，攻擊者正是利用該權杖繞過了所有的來源驗證 (Provenance Controls)。

這是一個深刻的結構性教訓：受信任發布 (Trusted Publishing) 只有在它是唯一的發布路徑時才有效。 只要遺留的舊式權杖與現代的來源驗證系統同時併存，這些權杖就會成為繞過防護機制的後門。

這次攻擊的複雜程度也值得關注。這並非一次簡單的突襲。攻擊者提前 18 小時部署了一個乾淨的誘餌包，在短短 39 分鐘內先後攻擊了當前版本和舊版本分支，為三大主流操作系統構建了平台特定的遠程訪問木馬（RAT）載荷，將 C2 通信偽裝成 npm 註冊表調用，並在攻擊執行後 36 秒內銷毀了所有取證證據。如此周密的計劃和執行表明，攻擊者擁有雄厚的資源和豐富的經驗。

補救措施(Remediation)

主要行動

立即將 axios 固定到已知安全的版本：（npm install axios@1.14.0 對於 1.x 分支）或 npm install axios@0.30.3（對於舊版 0.x 分支）。

針對不同情境的處理指令

應急緩解措施 (Interim Mitigations)

若您無法立即驗證並重新建置受影響的系統，請執行以下操作：

1. 阻斷 C2 通訊：將 sfrclak.com 與 142.11.206.73 加入防火牆黑名單（Blocklists）或 DNS 匯流陷阱 (Sinkholes)。
2. 執行安全安裝原則：在 CI/CD 環境中將 npm install --ignore-scripts 設定為常態政策，以防止 postinstall Hooks自動執行。
   更換所有憑證 (Rotate Credentials)：更換所有受影響系統可存取的憑證，包括：npm 權杖 (Tokens)、AWS 金鑰、SSH 私鑰、CI/CD 秘密資訊 (Secrets)、資料庫密碼以及 .env 檔案內容。

入侵後處置考量 (Post-Compromise Considerations)

若您發現任何 RAT 跡證，或確認 lockfile 曾安裝過 axios@1.14.1 或 axios@0.30.4，請將該系統視為「完全失守」：

1. 重建系統：從已知完好的映像檔 (Image) 或備份中重新建置。
2. 徹底更換金鑰：更換該系統上所有曾存放過的秘密資訊與憑證。
3. 稽核認證日誌：審核認證日誌 (Authentication logs)，檢查是否有源自受害主機的異常存取行為。
4. 檢查橫向移動 (Lateral Movement)：特別是在雲端環境中，檢查 IAM 憑證或 SSH 金鑰是否已被外洩，並導致攻擊者向其他主機滲透。

偵測指南：套件雜湊值 (用於偵測與驗證)

主機端入侵指標 (Host-level Indicators, IoC)

請在各平台檢查是否存在以下可疑路徑或檔案：

檢測命令

Orca Security 能提供什麼幫助？

Orca 協助客戶識別正在執行受污染 axios 版本的雲端工作負載（Cloud Workloads）與容器映像檔（Container Images）。除了單純的偵測，Orca 還能分析暴露情境 (Exposure Context)——包括資產是否可從網際網路存取、攻擊路徑的可達性以及資產的重要性，進而根據真實風險排定修補的優先順序。透過 Orca 的「新聞項目 (News Item)」視圖，安全團隊能直接掌握受影響的資產，確保優先處理最關鍵的系統。

若對 Orca 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/product-services-nav/info-security/orca