合法包投毒（Compromised Package / Package Takeover）指的是：攻击者不仿冒包名，而是直接拿到一个被大量项目信任的开源包的发布权限，把恶意代码当作官方"新版本"发出去。
为什么难防
开源包的所有权常常只系在一两个维护者账号上。攻击者用钓鱼、撞库、骗取发布令牌（token）等方式拿下这个账号后，所有元数据都是对的：包名对、源码仓库对、发布者也是本人账号。唯一变的是代码本身。
打个外卖的比方：还是同一家店、同一个招牌、同一个配送员；店悄悄换了老板，菜单没动，其中一道菜里加了别的东西。你照常点、照常吃。
Zod 这类被成千上万项目直接或间接依赖的基础库一旦被接管，影响会顺着依赖树往下蔓延。恶意版本通常在安装脚本（postinstall）或模块被 import 时执行一小段引导代码，再去远程拉取真正的载荷。引导代码可能只有几行，混在正常的代码 diff 里很不显眼；等它跑起来，就能读到构建环境里的全部环境变量——CI 令牌、云凭证、私有仓库密码——并把这些发往外部地址。
和相邻概念的区别
| 概念 | 攻击点 | 包名 | 典型特征 |
|---|---|---|---|
| 合法包投毒 | 维护者账号 / 发布权限 | 正品原名 | 版本号正常递增，代码里有后门 |
| 名字仿冒（Typosquatting） | 使用者的手误 | 拼写相近的山寨名 | 包名差一两个字母 |
| 依赖混淆（Dependency Confusion） | 私有仓库的解析顺序 | 与内部包同名 | 公开仓库上冒出"更高版本"的同名包 |
前两者的防线都在"你装了什么"，第三种更多是仓库配置问题。
日常怎么防
1. 锁版本 + 按锁安装：把 lockfile 提交进仓库，CI 里用 npm ci 一类的严格安装命令。它按 lockfile 记录的完整性哈希校验下载内容，被人换过就会直接失败。
2. 让升级慢半拍：新版本发布后隔一段时间再升。依赖机器人可以配置成只升级"发布满若干天"的版本，恶意版本往往在几小时到几天内被发现并撤下。
3. 收紧执行权限：能不开安装脚本就不开；CI 出网走白名单；构建凭据给最小权限、短有效期。这样即便装到了坏版本，它能带走的也有限。
已经中招后的恢复顺序
- 冻结：暂停部署，回滚到上一个已知正常的版本或镜像。
- 定位：对着 lockfile 和构建日志，确认坏版本是哪个、何时引入、进过哪些流水线。
- 清理：清空 CI 缓存、包管理器缓存、构建产物和镜像层，再重新安装。
- 轮换：凡是该环境能读到的密钥一律换掉——CI secrets、云凭证、发布令牌、数据库口令。这一步最容易被跳过，也最关键。
- 排查下游：如果坏版本进过发布流水线，把当时产出的制品也当作可疑对象处理。
具体受影响的版本号与处置细节，以官方安全公告为准。