裝過受污染 Jscrambler 點算？查清 npm 痕跡同即刻換走 secrets

Jscrambler 呢次供應鏈攻擊最麻煩嘅地方，係惡意套件出自正版 npm 名下，版本號亦睇落正常。自動更新工具、冇鎖實版本嘅 build，甚至只係啱啱重建過一次 CI runner，都有機會中招。升上乾淨版本只會截住下一次安裝，唔會收返已經俾人偷走嘅憑證。 以下資料截至 2026 年 7 月 17 日，事故調查之後仍可能更新。

攻擊者搶到發布權限，乾淨新版都照樣俾佢追上

iThome 報道，事故源頭係一部開發者電腦失守，機內嘅 GitHub SSH key 同 npm 發布憑證落入攻擊者手上。Jscrambler 最新事後報告再交代，攻擊者取得 GitHub repository 寫入權限，改動 GitHub Actions workflow，從 CI 偷出長效 npm token，再繞過原本發布流程直接向 npm registry 推惡意套件。公司初時撤銷錯咗憑證，每次推出乾淨新版後，攻擊者仍可用另一個 token 再推惡意版，雙方反覆爭奪 latest 標籤。

官方列出受污染嘅 jscrambler 版本係 8.14.0、8.16.0、8.17.0、8.18.0 同 8.20.0，乾淨版係 8.22.0。指定版本嘅 jscrambler-webpack-plugin、gulp-jscrambler、grunt-jscrambler 同 jscrambler-metro-plugin 亦會拉入受污染嘅 8.18.0。早期獨立分析曾話呢四個 helper package 本身冇惡意碼，兩邊其實講緊唔同層次：plugin 發布檔可以冇俾人植入，依賴解析後仍可帶入有事嘅核心套件。處理時應跟官方最新清單，唔好只掃 plugin 自己嘅程式碼。

圖片：Jscrambler

先查 lockfile，再追 CI 到底有冇真正執行

第一步係搜尋所有 repository 嘅 package-lock.json、npm-shrinkwrap.json、yarn.lock 同 pnpm-lock.yaml，包括舊 branch、release tag 同事故期間產生嘅 build artifact。除咗直接依賴 jscrambler，亦要查上述四個 helper package。工作目錄仍保留住嘅話，可用 npm ls jscrambler --all 睇實際依賴樹；本機 npm cache 就逐個跑 npm cache ls [email protected] 呢類查詢。cache 命中只可證明套件曾經下載，未足以證明惡意程式已執行，但係一條值得追落去嘅時間線索。

跟住要翻查 7 月 11 日之後嘅 GitHub Actions、GitLab CI、部署平台同自架 runner 記錄，搵 npm install、npm ci、CLI 執行時間、異常外連同新建程序。較早嘅惡意版本用 preinstall hook，安裝期間已可起動；獨立研究 SafeDep 指 8.18.0 同 8.20.0 改為放入正常程式入口，import 套件或執行 CLI 先觸發。即係話 --ignore-scripts 只擋到部分攻擊鏈，亦解釋咗點解單靠掃 lifecycle script 會漏嘢。

行過惡意版本，就當部機同 runner 已經失守

如果記錄確認受污染版本曾經裝過兼觸發過，就先隔離相關工作站或 self-hosted runner，再用可信裝置撤銷憑證。處理範圍至少包括 npm token、GitHub SSH key／PAT、CI/CD secrets、雲端 access key、部署憑證同 signing key；任何喺當時環境變數、設定檔或工作目錄出現過嘅秘密都要換。SafeDep 分析指惡意程式亦會針對瀏覽器資料、Bitwarden extension 同 session，所以開發者日常用機中招，風險會闊過單一 project。撤銷舊 token、檢查異常登入同發布記錄，再重建 runner 或重裝受影響主機，會穩陣過清走 node_modules 就算。

完成保安處理後，先喺乾淨環境重新產生 lockfile 或核實佢只指向安全版本，再用 npm ci 重建。npm 官方講明 npm ci 會照 lockfile 作 frozen install，唔會自行改寫依賴版本；所以一份鎖住惡意版嘅舊 lockfile，隔幾個月重跑仍然係事故入口。npm cache 亦要納入清理同取證，但唔好一開始就全數刪除，否則會抹走協助確認下載時間同版本嘅線索。

OIDC 可以縮短 token 壽命，但 workflow 權限仍要收緊

呢宗事故亦示範咗長效發布 token 點解咁危險：一經 CI 洩露，攻擊者可以喺撤銷前重複發布。npm Trusted Publishing 改用 OIDC，npm 會信任指定 GitHub Actions、GitLab CI 或 CircleCI workflow，每次發布先換取短效憑證，毋須長期保存一條可重用嘅 npm token。npm 官方建議啟用後封鎖傳統 token 發布；要求人手覆核嘅團隊仲可以只容許 staged publishing，再用 2FA 批准。

不過 OIDC 冇能力補救一條任人修改嘅 workflow。repository 寫入權限、branch protection、GitHub environment approval、第三方 Action pinning，同 permissions 最小化仍要逐項做好。雲端部署亦可跟 GitHub 官方做法，用 OIDC 換 AWS、Azure 或 GCP 短效權限，逐步減少 CI secrets。處理今次事故，應先用 lockfile 同 build 記錄確認惡意版本有冇跑過，再按最壞情況換證同重建環境。套件亦要升級，但淨係升級唔夠。

參考來源

• iThome — 針對NPM套件供應鏈攻擊事故，Jscrambler開發團隊公布調查結果 — original report
• Jscrambler Security Incident Postmortem — 涉事公司最新事後報告，列出攻擊鏈、受影響版本、helper package 同修復建議。
• SafeDep：Official jscrambler npm Package Compromised Across Multiple Releases — 獨立技術分析，拆解惡意程式觸發方式、版本演變同憑證風險。
• npm Docs：Trusted publishing for npm packages — npm 官方 OIDC 發布設定、支援平台、token 限制同 staged publishing 說明。
• npm Docs：npm cache — 核對 npm cache 查詢方式、儲存位置同完整性機制。
• npm Docs：npm ci — 核對 CI 會按 lockfile 作 frozen install，唔會自行修改依賴版本。
• GitHub Docs：Configuring OpenID Connect in cloud providers — GitHub 官方講解點用 OIDC 取代長效雲端 secrets，同點限制 token 發出條件。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。