软件供应链安全
官方 npm 包被投毒，AI 编程工具配置也被盯上了
您有没有遇到这样的情形，包名、发布者和版本号看起来都很正常。开发机照常执行 npminstall，流水线继续跑。直到安全通告发布，团队才意识到，恶意代码可能已经在开发环境或构建环境中执行。
7 月 11 日，Jscrambler 披露，Code Integrity 产品使用的jscrambler npm 包遭到未授权发布，其他产品未受影响。恶意版本包括 8.14.0、8.16.0、8.17.0、8.18.0 和 8.20.0。官方 7 月 13 日更新显示，npm 记录到 1479 次相关下载，其中包括关联包触发的依赖下载；8.22.0 为安全版本。
攻击者在数小时内多次调整触发方式。8.14.0、8.16.0 和 8.17.0 通过preinstall运行恶意载荷；8.18.0 和 8.20.0 把载荷移入包入口和 CLI 文件，在导入包或运行 CLI 时触发。只检查安装钩子，后两个版本可能漏过去。
图源：Jscrambler
01 从 preinstall 到包入口，触发方式变了
图源：Socket Research
npm 里，安装脚本一直是个让人又爱又烦的东西。很多包靠它做平台适配、编译准备、依赖检查，开发同学平时也不会每次都盯着它看。包来自官方名下，版本号看着正常，CI 里自动拉下来装一下，太常见了。
问题就卡在这里。preinstall跑得很早，早到很多安全检查还没来得及介入。它一旦在开发机、构建机、发布流水线里执行，就有机会看见本地配置、环境变量、临时目录、凭据文件，甚至一些平时没人特意盘点的工具配置。
这类事故复盘时，安全团队最累的地方往往不在漏洞编号，而在影响面。哪台机器装过，哪个 job 跑过，哪个 token 当时还有效，哪些构建产物后来又被继续使用。单看依赖清单，只能看到包进来了；要判断它碰过什么，还得把安装时的环境翻出来。
02 资产清单是理想，开发机现场是现实
这次公开分析里提到的目标比较杂：云凭据、CI token、浏览器会话、钱包、本地配置、Bitwarden vault，还有 Claude Desktop、Cursor 这类 AI 编程工具的配置文件。乍一看有点散，放到开发机器上就不散了。
开发环境本来就是一个“顺手”的地方。为了调试方便，云账号可能登着；为了发版方便，CI token 可能在环境变量里；为了提升效率，AI 编程工具也接进了工程上下文。大家都知道这些东西敏感，但在项目赶进度的时候，很多配置会先跑起来，后面再慢慢收敛。
攻击者不需要先摸清企业完整的业务系统。恶意代码只要在开发机或构建环境中执行，就会按既定路径搜集云凭据、CI token 和 AI 工具配置，再尝试对应的云账号、流水线或内部服务。
事件档案
受影响对象：jscrambler npm 恶意版本。
触发方式： 8.14.0、8.16.0、8.17.0 通过preinstall触发；8.18.0、8.20.0 在导入包或运行 CLI 时触发。
影响范围： 开发机和 CI/CD 构建环境，以及其中保存的凭据与配置。
排查重点： 核对受影响版本出现在哪些机器和构建任务中，确认是否触发过安装、导入或 CLI，并排查当时可访问的凭据与配置。
03 AI 编程工具配置也成了搜集目标
以前做凭据排查，大家比较容易想到云账号、Git token、npm token、SSH key、CI 密钥。现在还得把 AI 编程工具放进清单里。
图源：Socket Research
这不是说 AI 工具天然更危险。原因很朴素：它们为了方便读工程、调模型、接上下文，常常保存连接信息和配置文件。有些团队还会把内部知识库、代码仓库、插件服务接进去。平时看是效率工具，到了投毒脚本眼里，就是一批可以顺手翻的目录。
这事儿现在确实是个灯下黑。很多团队把 Git 密钥、云账号守得很紧，却很少回头看 AI 编程工具的配置目录：里面是否保存 API Key、token 或 MCP 服务凭据。
投毒脚本一旦跑在开发机上，攻击者不用从外面硬撬门，直接就在屋里翻柜子。
04 升级到安全版本后，还要核对受影响机器
遇到这类事件，改版本当然要做，删恶意包也要做。但如果只停在 package.json 和 lockfile，心里很难踏实。
排查时，先把影响面拉出来：哪些开发机、构建机和容器镜像出现过受影响版本；是否执行过安装、导入包或运行 CLI；构建日志能不能对上时间；临时目录、子进程和网络连接有没有异常；相关凭据有没有轮换；后续构建是否换过干净环境。
这些事没有一项很高级，麻烦的是信息太分散。记录齐，半天能说清；记录不齐，就只能翻 CI、查缓存、问开发、看终端日志，一点点往回拼。拼得出来还好，拼不出来，风险就只能先按更保守的方式处理。
05 修复完成后，关键检测再跑一遍
版本升级和凭据轮换做完，最好再做一次针对性复测。先看异常包版本和恶意代码执行能否触发告警，再看 CI 中的陌生二进制、异常外联和旧 token 使用是否留痕。开发机与构建机上的检测差异，也需要对照一次。
复盘时，先把几件事讲清楚：哪位触发的拉取，受影响版本在哪些机器上出现过，通过什么方式触发，当时又能访问哪些凭据。如果软件包进入开发环境和流水线时，来源、版本、内容和后续去向都有记录，这些问题就好回答得多。下次再碰到同类事件，团队不用从聊天记录里重新拼现场。
参考来源Jscrambler Security Advisory，Unauthorized Publication of a Malicious npm Package，2026 年 7 月。BleepingComputer，Hackers backdoor Jscrambler npm package with infostealer malware，2026 年 7 月 13 日。Reflectiz，Jscrambler npm Package Compromised: Why It Matters，2026 年 7 月。Socket.dev，jscrambler npm Package Compromised in Supply Chain Attack，2026 年 7 月 11 日。
