微軟旗下程式碼託管平台 GitHub 於 10 月 2 日宣布，新建立但尚未驗證的 npm 受信任發布（trusted publishing）設定，若在 48 小時內未完成首次發布，就會失效。這項措施源自資安業者 Bloom Security 的研究。研究指出，
攻擊者無須竊取憑證，就可能取得他人 npm 套件的發布權限，進而上傳惡意版本。逾 1,500 個套件曾暴露於此風險，累計下載量超過 1,000 萬次。
根據 GitHub 公告，新建立的受信任發布設定必須在兩天內成功發布一次。完成首次發布後，設定便會通過驗證，並綁定至儲存庫的不可變身分（immutable identity），之後不再受期限限制。
若要變更儲存庫或專案身分，則須建立新的信任關係，48 小時的驗證期限也會重新起算；一般編輯則不會重啟倒數。GitHub 表示，這項調整可降低只依賴儲存庫或專案名稱建立信任，卻因名稱日後易主而產生的風險。
此外，npm 不再接受來自 GitHub Actions（GitHub 自動化工作流程）issue_comment 事件的受信任發布權杖（token）；這項限制與既有的 pull_request_target 限制並行。
只認名稱、不認身分：SlugFest 攻擊如何成立
受信任發布於 2025 年 7 月在 npm 全面開放。開發者可透過持續整合與持續部署（CI/CD）平台，使用 OpenID Connect（OIDC）簽發的短期權杖發布套件，無須保存長期有效的 npm 密鑰。
Bloom Security 發現，npm 辨識儲存庫的方式存在缺口：在儲存庫首次發布版本前，npm 記錄的是「擁有者／儲存庫」名稱（slug），而非 GitHub 指派的永久 ID。Bloom Security 資安研究員 Golan Myers 形容：「這就像一把鎖只確認門牌地址，卻不確認屋主是誰。屋主搬走後，誰搬進來，誰就拿到鑰匙。」
因此，維護者若改名、轉移或刪除儲存庫，原名稱就可能被他人重新註冊。若受害者的受信任發布設定仍指向可被搶註的名稱，且原儲存庫從未發布過套件版本，攻擊者便可能利用重新註冊的儲存庫取得發布權限，並以合法套件名稱上傳惡意版本，沿用該套件既有的信譽、下載量與相依關係。Bloom Security 將此攻擊命名為
SlugFest。
Myers 強調，這種攻擊不需要內部資訊或竊取憑證，也不涉及競爭條件（race condition）。攻擊能否成立，唯一前提是儲存庫名稱可被搶註，而這取決於受害者如何管理儲存庫。
AI 代理可能放大風險
Bloom Security 提醒，AI 代理會自行解析相依套件，通常傾向使用最新版本，卻很少確認套件來源。若攻擊者透過遭搶註的名稱發布惡意版本，這些版本可能在未經人工審核的情況下被下載並執行。Bloom Security 已於 2026 年 6 月 6 日向 GitHub 通報此問題。
維護者應立即採取的措施
npm 套件維護者應採取以下措施：
- 稽核受信任發布綁定，確認其中列出的儲存庫仍由自己掌控。
- 若儲存庫曾改名或轉移，刪除舊的信任綁定，並以目前的儲存庫名稱重新建立。
- 持續監控非預期的 npm 套件發布事件。
- 儲存庫遭刪除、轉移或改名時，同步刪除對應的信任綁定。
本文轉載自 TheHackerNews。