GitHub为NPM可信发布设置48小时验证期限 阻断仓库名回收漏洞
内容提要
GitHub 调整 NPM 可信发布规则，新配置须在 48 小时内完成首次发布，否则失效。此举旨在修复仓库名回收漏洞：维护者重命名或删除仓库后，攻击者可注册同名仓库获取发布凭证，向原包推送恶意版本。约 1500 个包受影响。NPM 还限制 issue_comment 事件触发发布。
延伸解读
漏洞根源：信任绑定滞后
NPM 可信发布在配置完成首次成功发布前，仅依据 GitHub 仓库的所有者/仓库名和工作流文件名建立信任，未绑定仓库的不可变身份。这意味着一旦仓库被重命名、转移或删除，原仓库名可能重新开放，攻击者便可注册同名仓库并创建匹配的工作流，从而获取发布凭证。这种滞后绑定是仓库名回收漏洞的核心。
48 小时期限的实际作用
GitHub 要求新建的可信发布配置必须在 48 小时内完成首次成功发布，否则配置失效。发布成功后，配置将绑定到仓库的不可变身份，不再受此期限限制。若仓库或项目身份发生变化，维护者需建立新的信任配置并重新验证。普通编辑不会重置 48 小时期限，这有助于防止攻击者利用未验证的配置。
受影响范围与潜在风险
安全研究人员估计超过 1500 个 NPM 软件包受此漏洞影响，累计下载量超过 1000 万次。攻击者若成功利用，可以以原软件包名发布恶意版本，并沿用原包的名称和用户基础继续传播。这意味着受影响的包可能被植入恶意代码，而用户难以察觉，风险波及整个依赖链。
工作流触发事件的限制
NPM 已开始拒绝由 GitHub Actions 的 issue_comment 事件触发的可信发布令牌，而 pull_request_target 事件此前已受到限制。受影响的发布工作流可以改为使用 push、release、workflow_dispatch 等事件。这一调整进一步收窄了攻击面，维护者需检查并更新自己的发布流程，确保使用受支持的事件触发方式。
Q&A
NPM 可信发布是什么？
NPM 可信发布允许 GitHub Actions 使用短期 OIDC 令牌发布软件包，无需在工作流中保存长期访问令牌。
仓库名回收漏洞是如何被攻击者利用的？
如果维护者重命名、转移或删除仓库，原仓库名可能重新开放。攻击者可以注册同名仓库并创建名称匹配的工作流，从而取得 NPM 发布凭据，以原软件包名发布恶意版本。
GitHub 为修复仓库名回收漏洞采取了什么措施？
GitHub 宣布可信发布配置必须在创建后 48 小时内完成首次成功发布。发布成功后配置将绑定到仓库的不可变身份，不再受此期限限制。若仓库或项目身份发生变化，维护者需要建立新的信任配置并重新完成验证。
这个漏洞影响了多少个 NPM 软件包？
安全研究人员估计有超过 1500 个 NPM 软件包受这个漏洞影响，累计下载量超过 1,000 万次。
NPM 对可信发布的触发事件做了哪些限制？
NPM 开始拒绝由 GitHub Actions issue_comment 事件触发的可信发布令牌，pull_request_target 事件此前已经受到限制。受影响的发布工作流可以改成 push、release、workflow_dispatch 等事件。
48 小时验证期限的具体规则是什么？
新建配置如果在 48 小时内没有完成首次成功发布，配置就会失败，不能再继续用于发布软件包。发布成功后配置将绑定到仓库的不可变身份，不再受此期限限制。普通编辑不会重置 48 小时期限。
