axios被黑3小時，10萬項目差點中招

3月31日凌晨，全球下載量超10億次的 HTTP 客戶端庫 axios 遭遇供應鏈攻擊。攻擊者在 npm 上發布了兩個惡意版本（1.14.1 和 0.30.4），潛伏 3 小時后才被撤下。如果你的 CI/CD 管道在那個時間段跑過 npm install，可能已經中招。

這不是普通的憑證泄露。攻擊者先是通過定向社會工程+遠程控制木馬（RAT）攻陷了項目首席維護者 Jason Saayman 的個人電腦，再順藤摸瓜拿到 npm 發布權限。整個過程像極了電影里的"近身滲透"——不是打服務器，是打寫代碼的人。

3小時窗口期：攻擊時間線還原

根據 Saayman 發布的事后分析報告，事件發生在 2026 年 3 月 31 日 00:21 UTC 至 03:15 UTC 之間。攻擊者在這個窗口內完成了三件事：發布兩個惡意版本、植入名為 plain-crypto-js@4.2.1 的依賴包、給這個依賴加上遠程訪問木馬。

木馬支持 macOS、Windows、Linux 三平臺。換句話說，只要你在這 3 小時內執行過 npm install axios@1.14.1 或 axios@0.30.4，攻擊者就能遠程控制你的機器。

檢測方法很簡單：在項目根目錄跑下面這行命令——

grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json yarn.lock 2>/dev/null

如果返回任何結果，Saayman 的建議很直接：把這臺機器視為已淪陷，立即隔離處理。

03:15 UTC，npm 官方撤下惡意版本；14 分鐘后，plain-crypto-js 也被清理。從發現到止損，團隊反應算快的。但 3 小時對于自動化構建系統來說，足夠跑完幾百上千次部署。

攻擊鏈：為什么打 maintainer 比打代碼更有效

開源軟件供應鏈有個結構性漏洞：維護者個人賬號往往是單點故障。axios 有 109k GitHub star、每周 npm 下載量數千萬，但發布權限集中在少數人手里。

這次攻擊者沒有試圖破解 npm 的服務器，而是選擇了更省力的路徑——先社工拿到 maintainer 的信任，再種木馬控制其個人電腦。Saayman 的電腦一旦被控，npm 憑證、2FA 種子、甚至瀏覽器里的登錄會話都可能被 harvest。

這種模式不是孤例。2023 年以來，針對開源維護者的定向攻擊明顯增多：Python 的 ctx 包、PHP 的 php-pear、甚至 Linux 內核的維護者都遭遇過類似手法。攻擊者發現，與其挖 0day 打基礎設施，不如直接"借"維護者的鍵盤用用。

axios 團隊在報告中提到，這次攻擊"遵循了類似活動中記錄的模式"。翻譯成人話：這是有組織的、可復用的 playbook，不是腳本小子隨手一試。

善后：一次"全量清零"式的安全重建

事發后，Saayman 的處理方式堪稱激進：所有設備完全擦除，所有憑證全部重置，不分平臺、不分用途。個人賬號、工作賬號、甚至"其他身份"下的訪問權限一律推倒重來。

這種痛苦是必要的。RAT 木馬往往帶有持久化機制，單純改密碼、 revoke token 不夠——攻擊者可能留了后門，等著你放松警惕。

團隊還在推進幾項長期措施：強制硬件安全密鑰（FIDO2/WebAuthn）、發布流程的多人審批、CI/CD 環境的隔離加固。Saayman 特意強調"這個清單不是終點"，暗示供應鏈安全是個無底洞，得持續投入。

一個值得注意的細節：axios 在 GitHub 上發了一個 deprecation action（#10591），專門用于標記被污染的版本。這種"事后標記"機制在 npm 生態里并不常見，算是用工程手段彌補人腦記憶的短板。

10萬項目的隱形依賴：我們到底在信任誰

axios 的流行程度讓它成為供應鏈攻擊的高價值目標。GitHub 上 109k star 背后，是無數企業內部系統、SaaS 產品、甚至關鍵基礎設施的隱形依賴。

這次事件暴露了一個尷尬現實：現代軟件工程建立在"信任鏈"之上，而鏈條的薄弱環節往往是具體的人。你可以有完美的代碼審計、依賴掃描、SBOM 生成，但如果 maintainer 的筆記本電腦被種了木馬，這些防線形同虛設。

Saayman 在報告末尾留了一句："我們正在積極調查未授權訪問是如何獲得的，并審查安全態勢和訪問控制的各個方面。"措辭謹慎，沒有承諾時間表。

對于那 10 萬個直接或間接依賴 axios 的項目來說，3 月 31 日的凌晨可能是一次未被察覺的"擦肩而過"。你的構建日志里，有沒有那個時間段的 npm install？