Shields 供應鏈安全實錄CVE-2025-54313eslint-config-prettier 投毒事件的排查、風險評估與防護實踐【免費下載鏈接】shieldsConcise, consistent, and legible badges in SVG and raster format項目地址: https://gitcode.com/gh_mirrors/sh/shields本篇技術指南以 Shields 項目官方安全公告 frontend/blog/2025-07-26-CVE-2025-54313.md 為主體完整還原該次上游 npm 包投毒事件的處置思路包括漏洞影響的依賴鏈分析、項目代碼庫受影響面的排查結論、Windows 用戶的實際風險邊界以及基于倉庫真實 CI 配置npm ci與npm install的區(qū)別給出的可復現(xiàn)防護驗證。讀完本文你將掌握針對上游供應鏈包被投毒這一類事件的標準響應流程并能用同樣的方法審計自己的 npm 項目。事件背景CVE-2025-54313 是什么2025 年 7 月Shields 團隊在官方博客發(fā)布安全說明披露了一個涉及eslint-config-prettier包的供應鏈漏洞編號為CVE-2025-54313。該漏洞的核心要點如下漏洞類型供應鏈投毒supply chain compromise存在潛在的**遠程代碼執(zhí)行RCE**風險影響范圍僅影響 Windows 用戶這一點決定了整個風險面評估的邊界嚴重程度官方評級為High高危。eslint-config-prettier是 Prettier 官方生態(tài)中用于關閉與 ESLint 規(guī)則沖突的共享配置包被絕大多數(shù) ESLint 工程作為devDependencies引入屬于開發(fā)期依賴。正因如此這類包一旦被投毒惡意代碼會在開發(fā)者執(zhí)行npm install時依賴安裝階段觸發(fā)postinstall/install腳本于本地機器上執(zhí)行——這正是其被稱為供應鏈攻擊的原因攻擊者不直接攻擊目標項目而是攻擊目標項目所信任的上游依賴。受影響依賴鏈投毒波及的包族Shields 在公告中明確列出了本次事件中同樣受影響的包。值得注意的是這些包并非互不相關的孤立包而是圍繞 Prettier/ESLint 生態(tài)形成的一條依賴鏈eslint-config-prettier漏洞的直接載體eslint-plugin-prettiersynckiteslint-plugin-prettier的運行時依賴負責跨線程執(zhí)行同步任務pkgr/coresynckit的底層依賴napi-postinstall用于原生模塊安裝輔助的包這條鏈在倉庫的鎖文件中可以得到印證查看 package-lock.json 可以看到synckit0.11.13對pkgr/core的依賴聲明為^0.3.6鎖文件中解析并固定為0.3.6package-lock.json。也就是說eslint-config-prettier→eslint-plugin-prettier→synckit→pkgr/core構成了完整的傳遞依賴路徑任何一個上游環(huán)節(jié)被投毒理論上都會沿著這條鏈傳導到所有依賴方。項目實際受影響面版本排查結論針對這次事件Shields 團隊在倉庫中逐一核對了這些包的實際聲明版本與解析版本結論是項目代碼庫中未使用任何受影響版本。根目錄 package.json 中eslint-config-prettier聲明為^10.1.8eslint-plugin-prettier聲明為精確版本5.5.6結合package-lock.json鎖定的解析結果均未落入 CVE 波及的版本區(qū)間上游已采取行動截至公告發(fā)布時npm 上已移除受影響版本從源頭上切斷了新安裝的可能生產(chǎn)環(huán)境未發(fā)現(xiàn)相關問題公告明確目前未在生產(chǎn)環(huán)境中發(fā)現(xiàn)與該漏洞相關的任何問題。需要特別強調(diào)的是這一未受影響結論針對的是倉庫本身及其正常運行流程但風險并未完全歸零——原因在于版本聲明中的^前綴詳見下一節(jié)。殘余風險^前綴、Windows 與npm install的組合雖然倉庫鎖定版本是安全的但 Shields 在公告中誠實指出了一處殘余風險面項目在package.json中對eslint-config-prettier使用了^前綴^10.1.8對于不讀取package-lock.json、直接以package.json為準執(zhí)行npm install的場景npm 會按^語義拉取最新的兼容版本10.1.8 11.0.0如果該操作發(fā)生在上游尚未移除受影響版本的時間窗口內(nèi)且執(zhí)行機器是Windows就可能裝到被投毒的版本并觸發(fā)惡意代碼執(zhí)行。這個風險的實際受害者畫像非常具體fork 倉庫的貢獻者、以及在自己 Windows 開發(fā)機上直接npm install的開發(fā)者——他們并不一定使用與主倉庫一致的鎖文件。因此公告給出的明確建議是任何曾在 Windows 機器上對這些包執(zhí)行過npm install的人都應檢查自己的系統(tǒng)是否存在被入侵的跡象如異常的進程、計劃任務、啟動項、可疑的 shell 歷史等。CI 為何幸免npm ci與npm install的安全差異公告中提到該問題似乎未影響我們的 CI 環(huán)境這是一個可以用倉庫配置直接驗證的結論。首先確認 Windows CI 的存在查看 .github/workflows/test-main.ymltest-main是倉庫中唯一的 Windows 任務其策略矩陣為test-main: strategy: matrix: os: [ubuntu-latest, windows-latest] runs-on: ${{ matrix.os }}也就是說test-main確實會在windows-latest上運行CI 面覆蓋了 Windows。關鍵在于依賴安裝方式——所有 CI 任務都通過統(tǒng)一的 setup action 安裝依賴見 .github/actions/setup/action.yml- name: Install dependencies if: ${{ inputs.cypress false }} run: | echo skipping cypress binary npm ci shell: bash這里使用的是npm ci而非npm install兩者的核心差異決定了安全結果對比維度npm cinpm install依賴解析依據(jù)嚴格按package-lock.json安裝^前綴不生效按package.json的^/~語義解析可能浮動到新版本鎖文件處理要求鎖文件與package.json一致否則直接報錯會更新鎖文件是否執(zhí)行 install 腳本執(zhí)行但只裝鎖定的版本執(zhí)行供應鏈風險鎖定版本可審計、可復現(xiàn)被投毒窗口極小安裝時刻可能拉到剛被投毒的新版本因此CI 的 Windows 任務雖然存在但由于npm ci嚴格使用鎖文件即便上游投毒版本恰好處于可安裝狀態(tài)CI 也只會安裝鎖文件中明確記錄的安全版本投毒版本根本沒有進入 CI 的機會。另一個細節(jié)同樣值得注意倉庫中確實存在使用npm install的流程即 badge-maker 包的冒煙測試 .github/workflows/test-package-cli.yml但它運行在ubuntu-latest上不涉及 Windows 攻擊面與本次漏洞的觸發(fā)條件Windows不匹配因而不在風險范圍內(nèi)。從本次事件提煉的供應鏈防護清單綜合 Shields 此次處置的全過程可以沉淀出一套可復用的 npm 項目供應鏈防護實踐以鎖文件為唯一事實來源CI 與本地開發(fā)統(tǒng)一使用npm ci杜絕^浮動版本進入安裝流程區(qū)分運行平臺審計風險面漏洞常帶有平臺特異性本次僅 Windows風險評估需按OS × 依賴安裝方式 × 版本解析方式組合逐一排查而非一刀切關注postinstall/install腳本類依賴投毒代碼通常在安裝階段執(zhí)行對帶腳本的原生/工具類包如napi-postinstall應提高警惕及時核對上游處置狀態(tài)投毒事件發(fā)生后上游往往會在短時間內(nèi)移除問題版本應確認自身的鎖定版本與聲明區(qū)間并關注上游的后續(xù)發(fā)布持續(xù)監(jiān)控Shields 表示會持續(xù)跟進該漏洞對自建 CI/生產(chǎn)環(huán)境同樣建議將此類供應鏈告警納入常規(guī)巡檢。結語CVE-2025-54313 事件是一次典型的開發(fā)期依賴投毒攻擊Shields 的應對為同類項目提供了一個完整范本先定位受影響依賴鏈再以鎖文件核驗版本接著按平臺與安裝方式界定風險面最后明確 CI 與生產(chǎn)環(huán)境的實際暴露情況。對于任何維護 npm 項目的團隊而言將npm ci、精確版本審計與供應鏈監(jiān)控固化為默認實踐是抵御此類攻擊最直接、成本最低的手段?！久赓M下載鏈接】shieldsConcise, consistent, and legible badges in SVG and raster format項目地址: https://gitcode.com/gh_mirrors/sh/shields創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Shields 供應鏈安全實錄：CVE-2025-54313（eslint-config-prettier 投毒事件）的排查、風險評估與防護實踐
Shields 供應鏈安全實錄CVE-2025-54313eslint-config-prettier 投毒事件的排查、風險評估與防護實踐【免費下載鏈接】shieldsConcise, consistent, and legible badges in SVG and raster format項目地址: https://gitcode.com/gh_mirrors/sh/shields本篇技術指南以 Shields 項目官方安全公告 frontend/blog/2025-07-26-CVE-2025-54313.md 為主體完整還原該次上游 npm 包投毒事件的處置思路包括漏洞影響的依賴鏈分析、項目代碼庫受影響面的排查結論、Windows 用戶的實際風險邊界以及基于倉庫真實 CI 配置npm ci與npm install的區(qū)別給出的可復現(xiàn)防護驗證。讀完本文你將掌握針對上游供應鏈包被投毒這一類事件的標準響應流程并能用同樣的方法審計自己的 npm 項目。事件背景CVE-2025-54313 是什么2025 年 7 月Shields 團隊在官方博客發(fā)布安全說明披露了一個涉及eslint-config-prettier包的供應鏈漏洞編號為CVE-2025-54313。該漏洞的核心要點如下漏洞類型供應鏈投毒supply chain compromise存在潛在的**遠程代碼執(zhí)行RCE**風險影響范圍僅影響 Windows 用戶這一點決定了整個風險面評估的邊界嚴重程度官方評級為High高危。eslint-config-prettier是 Prettier 官方生態(tài)中用于關閉與 ESLint 規(guī)則沖突的共享配置包被絕大多數(shù) ESLint 工程作為devDependencies引入屬于開發(fā)期依賴。正因如此這類包一旦被投毒惡意代碼會在開發(fā)者執(zhí)行npm install時依賴安裝階段觸發(fā)postinstall/install腳本于本地機器上執(zhí)行——這正是其被稱為供應鏈攻擊的原因攻擊者不直接攻擊目標項目而是攻擊目標項目所信任的上游依賴。受影響依賴鏈投毒波及的包族Shields 在公告中明確列出了本次事件中同樣受影響的包。值得注意的是這些包并非互不相關的孤立包而是圍繞 Prettier/ESLint 生態(tài)形成的一條依賴鏈eslint-config-prettier漏洞的直接載體eslint-plugin-prettiersynckiteslint-plugin-prettier的運行時依賴負責跨線程執(zhí)行同步任務pkgr/coresynckit的底層依賴napi-postinstall用于原生模塊安裝輔助的包這條鏈在倉庫的鎖文件中可以得到印證查看 package-lock.json 可以看到synckit0.11.13對pkgr/core的依賴聲明為^0.3.6鎖文件中解析并固定為0.3.6package-lock.json。也就是說eslint-config-prettier→eslint-plugin-prettier→synckit→pkgr/core構成了完整的傳遞依賴路徑任何一個上游環(huán)節(jié)被投毒理論上都會沿著這條鏈傳導到所有依賴方。項目實際受影響面版本排查結論針對這次事件Shields 團隊在倉庫中逐一核對了這些包的實際聲明版本與解析版本結論是項目代碼庫中未使用任何受影響版本。根目錄 package.json 中eslint-config-prettier聲明為^10.1.8eslint-plugin-prettier聲明為精確版本5.5.6結合package-lock.json鎖定的解析結果均未落入 CVE 波及的版本區(qū)間上游已采取行動截至公告發(fā)布時npm 上已移除受影響版本從源頭上切斷了新安裝的可能生產(chǎn)環(huán)境未發(fā)現(xiàn)相關問題公告明確目前未在生產(chǎn)環(huán)境中發(fā)現(xiàn)與該漏洞相關的任何問題。需要特別強調(diào)的是這一未受影響結論針對的是倉庫本身及其正常運行流程但風險并未完全歸零——原因在于版本聲明中的^前綴詳見下一節(jié)。殘余風險^前綴、Windows 與npm install的組合雖然倉庫鎖定版本是安全的但 Shields 在公告中誠實指出了一處殘余風險面項目在package.json中對eslint-config-prettier使用了^前綴^10.1.8對于不讀取package-lock.json、直接以package.json為準執(zhí)行npm install的場景npm 會按^語義拉取最新的兼容版本10.1.8 11.0.0如果該操作發(fā)生在上游尚未移除受影響版本的時間窗口內(nèi)且執(zhí)行機器是Windows就可能裝到被投毒的版本并觸發(fā)惡意代碼執(zhí)行。這個風險的實際受害者畫像非常具體fork 倉庫的貢獻者、以及在自己 Windows 開發(fā)機上直接npm install的開發(fā)者——他們并不一定使用與主倉庫一致的鎖文件。因此公告給出的明確建議是任何曾在 Windows 機器上對這些包執(zhí)行過npm install的人都應檢查自己的系統(tǒng)是否存在被入侵的跡象如異常的進程、計劃任務、啟動項、可疑的 shell 歷史等。CI 為何幸免npm ci與npm install的安全差異公告中提到該問題似乎未影響我們的 CI 環(huán)境這是一個可以用倉庫配置直接驗證的結論。首先確認 Windows CI 的存在查看 .github/workflows/test-main.ymltest-main是倉庫中唯一的 Windows 任務其策略矩陣為test-main: strategy: matrix: os: [ubuntu-latest, windows-latest] runs-on: ${{ matrix.os }}也就是說test-main確實會在windows-latest上運行CI 面覆蓋了 Windows。關鍵在于依賴安裝方式——所有 CI 任務都通過統(tǒng)一的 setup action 安裝依賴見 .github/actions/setup/action.yml- name: Install dependencies if: ${{ inputs.cypress false }} run: | echo skipping cypress binary npm ci shell: bash這里使用的是npm ci而非npm install兩者的核心差異決定了安全結果對比維度npm cinpm install依賴解析依據(jù)嚴格按package-lock.json安裝^前綴不生效按package.json的^/~語義解析可能浮動到新版本鎖文件處理要求鎖文件與package.json一致否則直接報錯會更新鎖文件是否執(zhí)行 install 腳本執(zhí)行但只裝鎖定的版本執(zhí)行供應鏈風險鎖定版本可審計、可復現(xiàn)被投毒窗口極小安裝時刻可能拉到剛被投毒的新版本因此CI 的 Windows 任務雖然存在但由于npm ci嚴格使用鎖文件即便上游投毒版本恰好處于可安裝狀態(tài)CI 也只會安裝鎖文件中明確記錄的安全版本投毒版本根本沒有進入 CI 的機會。另一個細節(jié)同樣值得注意倉庫中確實存在使用npm install的流程即 badge-maker 包的冒煙測試 .github/workflows/test-package-cli.yml但它運行在ubuntu-latest上不涉及 Windows 攻擊面與本次漏洞的觸發(fā)條件Windows不匹配因而不在風險范圍內(nèi)。從本次事件提煉的供應鏈防護清單綜合 Shields 此次處置的全過程可以沉淀出一套可復用的 npm 項目供應鏈防護實踐以鎖文件為唯一事實來源CI 與本地開發(fā)統(tǒng)一使用npm ci杜絕^浮動版本進入安裝流程區(qū)分運行平臺審計風險面漏洞常帶有平臺特異性本次僅 Windows風險評估需按OS × 依賴安裝方式 × 版本解析方式組合逐一排查而非一刀切關注postinstall/install腳本類依賴投毒代碼通常在安裝階段執(zhí)行對帶腳本的原生/工具類包如napi-postinstall應提高警惕及時核對上游處置狀態(tài)投毒事件發(fā)生后上游往往會在短時間內(nèi)移除問題版本應確認自身的鎖定版本與聲明區(qū)間并關注上游的后續(xù)發(fā)布持續(xù)監(jiān)控Shields 表示會持續(xù)跟進該漏洞對自建 CI/生產(chǎn)環(huán)境同樣建議將此類供應鏈告警納入常規(guī)巡檢。結語CVE-2025-54313 事件是一次典型的開發(fā)期依賴投毒攻擊Shields 的應對為同類項目提供了一個完整范本先定位受影響依賴鏈再以鎖文件核驗版本接著按平臺與安裝方式界定風險面最后明確 CI 與生產(chǎn)環(huán)境的實際暴露情況。對于任何維護 npm 項目的團隊而言將npm ci、精確版本審計與供應鏈監(jiān)控固化為默認實踐是抵御此類攻擊最直接、成本最低的手段?！久赓M下載鏈接】shieldsConcise, consistent, and legible badges in SVG and raster format項目地址: https://gitcode.com/gh_mirrors/sh/shields創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考