· adswds-team · 安全 · 4 min read
npm 可信发布 48 小时验证：仓库名回收漏洞之后，CI 要改什么
蓝点网报道：GitHub 为 npm Trusted Publishing 设置 48 小时内必须首次成功发布，阻断研究员发现的仓库名回收（SlugFest）风险；并拒绝 issue_comment 事件令牌。广告与落地前端的发布流水线应按此收紧。
据蓝点网报道（2026-10-14），GitHub 调整 npm Trusted Publishing 规则：新建的可信发布配置若在 48 小时内未完成首次成功发布，将失效、不能再用于发包。此举针对研究人员发现的仓库名回收风险——维护者重命名、转移或删除仓库后，原 owner/repo 名可能重新开放，攻击者注册同名仓库并放置匹配工作流，即可能在配置尚未绑定不可变仓库身份前，骗取对他人包名的发布权。npm 同时拒绝来自 GitHub Actions issue_comment 事件的可信发布令牌（此前已限制 pull_request_target）。
一句话：OIDC「无长期 token」不等于「信任配置可以无限期挂着不用」。
一、漏洞与修复在解决什么
| 项 | 说明（据蓝点网 / 公开变更） |
|---|---|
| 原风险 | 信任配置在首次成功发布前，主要核对可读仓库名 + 工作流文件名，未钉死不可变仓库 ID |
| 攻击面 | 弃用/改名后的 slug 被抢注 → 同名 Actions → 向原包推恶意版本 |
| 修复 | 未验证配置 48h 内必须首次成功发布；成功后绑定不可变身份，普通编辑不重置倒计时 |
| 身份变更 | 仓库/项目身份变化需新建信任关系并重新走 48h 窗口 |
| 事件收紧 | 拒绝 issue_comment 等易被滥用的触发源；改用 push / release / workflow_dispatch 等 |
Trusted Publishing 本意是用短期 OIDC 取代长期 npm token——在 Shai-Hulud / TeamPCP 一类蠕虫之后被大力推广。本次说明：自动化发布的信任锚点仍要防「名字可回收」。
二、广告 / 落地前端 CI 检查清单
- 列出所有使用 Trusted Publishing 的包（落地组件、共享 UI、Worker 工具包）；
- 新建配置后 48h 内完成一次真实成功 publish（可先发 patch）；
- 工作流触发事件不含
issue_comment/ 高风险 PR 事件； - 仓库转移、改名计划提前重建 trust，而不是事后救火；
- 过期配置重建，勿假设「设置页还看得到 = 还能发」；
- 仍保留：lockfile 校验、最小权限、双人发布复核。
同日蓝点网亦报道 Docker Hub 账户转组织时个人令牌未正确撤销（CVE 评分 9.4）——发布身份生命周期是同一类问题：改了组织形态，旧凭证还在。
三、和流量业务的关系
对投放站而言，被投毒的前端包可以改跳转、偷点击 ID、挂马。入口流量过滤挡不住「你自己 CI 发上去的脏构建」。
访客规则管流量结构；Trusted Publishing 纪律管构建是否还是你的。
四、小结
蓝点网报道的 npm 48 小时验证，是把「创建信任配置」从开放式挂起改成限时激活。维护广告落地与共享前端包的团队，应本周内审计 Trusted Publishing 配置与 Actions 触发源，避免在仓库更名/转移窗口被仓库名回收击穿。
相关阅读：TeamPCP 卧底与凭证轮换、axios 维护者劫持。
