NPM 套件劫持是一種軟體供應鏈攻擊，其手法是將對套件的信任轉化為攻擊途徑。只要攻擊者能夠控制發布該套件的帳戶，便無需修改儲存庫中的程式碼。
這正是讓受信賴的 npm 套件成為如此強大的攻擊面之原因。當維護者帳戶遭到入侵時，凡是安裝了受影響套件的專案，都可能在例行依賴項更新過程中暴露於風險之中。2026 年 3 月的 Axios 事件便顯示，一個遭入侵的 npm 帳戶，即使未對 axios 原始碼進行任何可見的修改，仍足以讓每週超過 1 億次的下載量面臨風險。
了解 npm 套件劫持的運作原理，有助於資安團隊建立能針對實際攻擊路徑的防護措施，而非僅針對多數團隊會審查的原始檔案。
Axios npm 攻擊事件始末
Axios npm 攻擊事件是一起維護者帳戶遭劫持的事件，導致一個受信賴的套件淪為惡意軟體的傳播載體。攻擊者入侵了 axios 主要維護者的 npm 帳戶，將註冊電子郵件地址變更為攻擊者所控制的地址，並將合法維護者鎖在帳戶之外。
這是一次精心策劃且有預謀的攻擊。在有效載荷被觸發前約 18 小時，攻擊者先發布了一個誘餌包，藉此建立發布紀錄，避免立即引起懷疑。隨後，在約 39 分鐘內，攻擊者接連發布了兩個惡意版本：現代發行分支的 axios 1.14.1，以及舊版分支的 axios 0.30.4。
這兩條發布線是同時發佈的，以達到最大曝光效果。此舉增加了現有環境與舊版環境透過標準更新機制拉取受感染套件的可能性。
package.json 中的單一行如何成為攻擊途徑
在 npm 供應鏈攻擊中，package.json 中的單一依賴項變更就可能成為整個攻擊路徑。在 Axios 事件中，由於惡意行為是透過新的依賴項引入的，因此無需修改任何 Axios 原始碼檔案。
該依賴項是透過 npm 的 postinstall 鉤子執行的。只要開發人員的工作站、CI/CD 管道或建置系統執行了 npm install，惡意套件便會聯繫攻擊者控制的伺服器，取得針對特定作業系統的載荷，並開始執行。
這些載荷是針對 macOS、Windows 和 Linux 系統所準備的。此次攻擊在設計上即為跨平台攻擊。執行後，載入程式會清除自身留下的痕跡，並將原始的 package.json 檔案替換為偽造版本，使得後續的鑑識分析難度大幅增加。
為何傳統的程式碼審查未能察覺 Axios 的攻擊
傳統的程式碼審查旨在檢查儲存庫內的原始碼變更，但此次攻擊途徑並未存在於 Axios 的原始碼中。Axios 攻擊並未依賴可見的儲存庫變更，因為惡意邏輯存在於一個獨立的依賴項中，而非 Axios 的原始碼內。
這一點差異至關重要。審查人員查看套件更新時，看到的不過是 package.json 檔案中新增的一行依賴項。實際的惡意行為，只有在依賴項被解析並安裝後才會顯現。
這就是為什麼僅靠基於 diff 的審查，很難偵測到可信賴套件的攻擊。儘管該套件看起來仍足夠合法，足以通過常規開發工作流程，但攻擊路徑卻位於大多數團隊所檢查的原始碼檔案之外。
為什麼爆炸半徑涵蓋了包裹所接觸的一切
受感染的 npm 套件所造成的影響範圍，並非該套件本身。其影響範圍涵蓋該套件所觸及的一切。
對大多數組織而言，這包括具備高階權限的 CI/CD 管道、含有 SSH 金鑰與雲端憑證的開發者端點、擁有構建產出庫寫入權限的構建伺服器，以及連接到生產環境系統的部署工具。惡意套件無需持續存在於依賴項樹中即可造成損害，它只需一個受信任的執行點即可。
正因如此，Axios 事件的重要性已超越 JavaScript 套件管理的範疇。基於 postinstall 的安全漏洞，可能將一次普通的安裝事件轉變為憑證竊取、橫向移動，或對下游基礎設施的存取。
Axios 攻擊事件所揭露的結構性弱點
Axios 事件揭露了現代軟體開發環境中普遍存在的結構性弱點。這些並非罕見的邊緣案例，而是許多組織中的常規假設。
信任套件維護者的身分
npm 套件的可信度通常取決於發布該套件的維護者帳戶。若該帳戶遭竊或遭釣魚攻擊，攻擊者將繼承與合法維護者相同的發布權限。
浮動依賴項版本
採用浮動版本或鬆散固定版本的版本管理方式，會增加遭受惡意版本釋出的風險。新發布的遭篡改版本可能在未經刻意批准的情況下，自動進入系統環境。
未受監控的安裝後腳本
npm 的 postinstall 腳本可以以安裝程序的權限執行任意程式碼。許多組織並未在執行前檢查或限制生命週期腳本。
執行時可見性受限的 CI/CD 管道
CI/CD 管道通常擁有對內部系統、建置基礎架構及雲端環境的廣泛存取權限。這些管道往往預設被視為可信賴，且在安裝時極少會針對惡意套件行為進行監控。
未受完整安全防護涵蓋的開發者端點
開發人員的機器儲存著高價值資產，包括 SSH 金鑰、雲端憑證及企業憑證。開發人員的終端點也常成為攻擊目標，因為相較於生產系統，這些終端點的可視性較低，且執行時控制措施也較少。
不使用快速輪替觸發器的憑證儲存庫
軟體供應鏈攻擊往往會演變成憑證外洩事件。許多團隊至今仍未建立可靠的工作流程，用以識別可能已外洩的機密資訊並立即進行輪替。
哪些安全控制措施本可改變結果
若能實施三類安全控制措施，便能大幅減輕 Axios 遭受攻擊所造成的影響。這三項控制措施分別針對攻擊鏈中的不同環節：套件執行、憑證外洩，以及依賴項可見性。
1. 安裝前的套件層級惡意軟體掃描
套件層級的惡意軟體掃描有助於在惡意依賴項執行前加以阻擋。這在 npm 攻擊中至關重要，因為 postinstall 鉤子會在安裝過程中執行，一旦套件被拉取，便幾乎沒有時間進行人工審查。
在安裝前掃描套件、依賴項及生命週期腳本，可在套件抵達開發人員終端裝置或 CI/CD 環境之前，識別已知的惡意軟體、可疑行為、漏洞以及硬編碼的機密資訊。
MetaDefender Software Supply Chain 是OPSWAT專為驗證軟體元件、供應商及建置管道所設計的軟體供應鏈安全解決方案。該方案採用多引擎威脅偵測技術，包含運用 Metascan 跨 30 多種防毒引擎進行多重掃描，在軟體套件進入開發生命週期之前，即對其進行惡意軟體、漏洞及硬編碼機密資訊的檢查。
2. 透過輪替觸發器進行主動式祕密管理
主動的機密管理能降低成功入侵事件的危害程度。當發現可疑封包時，團隊需要一套應對流程，將本機憑證、SSH 金鑰、憑證代碼及管道機密視為可能已外洩，並迅速進行輪替。
硬編碼機密偵測同樣旨在達成此目標。惡意套件雖能從記憶體或磁碟中竊取機密，但程式碼或依賴項中已存在的暴露機密，則增添了另一層本可避免的風險。
3.Supply Chain 與依賴關係監控
供應鏈可視性有助於團隊在意外的套件變更演變成下游問題之前及早發現。資安團隊需要掌握哪些套件已安裝、哪些版本已被鎖定、有哪些新依賴項出現，以及這些元件正在何處運行。
若缺乏對依賴項的可視化與監控，系統遭入侵的首個跡象，可能是原始安裝事件早已過去許久之後，才出現的憑證濫用或基礎設施遭誤用等情況。
深入了解Software Supply Chain
Software 的安全性取決於在執行前檢查套件、監控新的依賴項，以及在套件遭到入侵後降低憑證外洩的風險。
觀看隨選視訊研討會：Software Supply Chain 風險——攻擊者所利用的薄弱環節
常見問題
什麼是 npm 供應鏈攻擊？
所謂的 npm 供應鏈攻擊，是指在正常的軟體開發過程中，透過 npm 生態系統植入惡意程式碼。攻擊者通常透過入侵維護者帳戶、發布欺騙性套件，或是在開發人員與 CI/CD 系統會自動安裝的依賴項中植入惡意行為來達成此目的。
攻擊者是如何入侵 Axios npm 套件的？
攻擊者入侵了 axios 主要維護者的 npm 帳戶，並利用該發布權限，在 1.x 和 0.x 兩個發行分支中發布了惡意版本。攻擊者還將帳戶電子郵件更改為由其控制的地址，藉此持續掌控該套件。
Axios 攻擊事件中的惡意軟體做了什麼？
在 Axios 攻擊事件中，該惡意軟體利用安裝後鉤子（postinstall hook）在執行 npm install 時進行運作。該鉤子會聯繫攻擊者控制的伺服器，下載適用於 macOS、Windows 或 Linux 的遠端存取木馬程式，並將其啟動；隨後，它會試圖透過將套件元資料替換為偽造內容來消除蹤跡。
為什麼程式碼審查未能發現 Axios 的供應鏈攻擊？
程式碼審查未能偵測到 Axios 攻擊，因為惡意邏輯並非源自 Axios 的原始碼。從儲存庫層面可見的變更僅是 package.json 中的依賴項條目，而實際的惡意軟體則是透過一個超出常規原始碼審查範圍的外部套件所植入的。
組織該如何在安裝前偵測惡意 npm 套件？
組織可透過在執行前掃描套件內容、依賴關係樹及生命週期腳本，在安裝前偵測惡意 npm 套件。有效的管控措施應結合惡意軟體掃描、依賴關係分析、政策執行以及 CI/CD 整合，以便在可疑套件進入開發或建置環境之前即予以阻擋。
版本鎖定能否防止 npm 供應鏈攻擊？
版本固定可透過限制自動升級，降低因新發布的惡意版本所造成的風險。然而，版本固定並不能消除供應鏈風險，因為被固定的版本可能早已遭到入侵，或仍存在其他信任失效的問題。若能結合完整性驗證、套件檢查及執行時控制措施，版本固定將發揮最佳效果。
