一只蠕虫，正在啃穿 AI 时代的供应链

一个版本号，就能让整条供应链出血。

2025 年 11 月 24 日，安全厂商 Socket 与 Snyk 披露：攻击者向 npm 发布了被植入恶意代码的 Tensorlake 包——版本 0.5.144，内嵌自复制蠕虫 Shai-Hulud 的新变种（攻击者自称"Shai-Hulud: The Second Coming"）。它偷开发者密钥、翻浏览器里存的加密货币凭据，然后拿着偷来的发布凭证，继续向下游包传播。这不是一次孤立投毒，而是一台自我复制的供应链攻击机器再次上电。

🪱 蠕虫回来了：0.5.144 发生了什么

先看事实层面到底发生了什么。

Shai-Hulud 并非新面孔。据 Wiz、Socket 等多家安全厂商的复盘，这个蠕虫首次现身是 2025 年 9 月 14 日：24 小时内感染了 187 个 npm 包，其中包括周下载量约 200 万的 @ctrl/tinycolor。而据 Snyk 与 BleepingComputer 对第二波疫情的追踪，从 11 月 24 日起的 24 小时内，受影响包数量飙升至 800 余个，波及 Zapier、PostHog、AsyncAPI 等知名组织。Tensorlake 0.5.144 正是这一波里被确认的感染点之一。

恶意载荷是 Shai-Hulud 蠕虫的新变种，这个家族最标志性的特征就是"自我复制"——它不是打一枪换一个地方，而是把每一个受害环境都变成下一个发射台。

它的能力清单有三条：窃取开发者本地密钥与 CI 环境变量；定向收割浏览器存储的加密货币凭据；最关键的一条——利用偷到的 npm 发布凭证，向受害者有权发布的其他包继续投毒。

把这条链画出来，你会看到它为什么可怕：

注意图里那个回到 B 的箭头。传统供应链攻击是“一次投放、坐等收获”，而 Shai-Hulud 是“投放即扩散”——每一次成功的感染，都会产生新的攻击起点。防御方面对的不是一个漏洞，而是一条指数曲线：第一波 187 个包，第二波 800 多个，数字本身就是蠕虫复制效率的直接证明。

而这也解释了为什么业界私下里对这类事件格外紧张：蠕虫化的供应链攻击，留给应急响应的窗口是按小时计的。等你发完公告，下游可能已经被滚了不止一轮。

🤖 为什么 AI 基础设施成了肥肉

金句先放这儿：AI 越热，依赖树越深，蠕虫的土壤越肥。

Tensorlake 属于 AI 数据与基础设施生态的一环，这类包的典型用户是谁？是在本地和 CI 环境里大量配置了云厂商密钥、模型 API Key、GitHub Token 的开发者。换句话说，装这类包的人，机器上的“钥匙串”密度远高于普通业务开发者。

这就构成了一个精准的猎场逻辑：

• 钥匙多：AI 开发环境天然要接云、接模型服务、接代码托管，本地凭据种类和数量都远超均值；
• 权限高：为了让自动化顺畅，很多团队给发布 Token、部署 Token 开了过大的权限；
• 更新频繁：AI 相关包迭代极快，依赖锁文件经常被放宽，恶意补丁版本很容易被自动拉取。

把当前主流的供应链攻击面放到一张定位图上看，会看得更清楚：

看坐标分布就明白了：AI 基础设施包、CI 发布凭证、开发者本地环境全部挤在右下角——依赖热度高、防御成熟度低的“优先加固区”；而左上、右上两个高防御象限里几乎没有热门生态的身影。热度越高的地方防御越跟不上，这不是巧合，是行业把速度置于信任之上的必然结果。

一位做开源安全的朋友说过一句被圈内反复引用的话：“开发者把最值钱的东西，放在了防护最差的地方。”用在这次的 Tensorlake 事件上，严丝合缝。

🔑 一把凭证，撬动整条链

这次事件最值得展开的，不是窃密本身，而是第三条能力：用被盗凭证继续发布。

npm 生态的信任模型，本质上建立在“发布凭证”之上。谁能拿到某个维护者的发布 Token，谁就能以合法身份向全世界推送任意代码——版本号正常、签名流程正常、下载量正常，唯一不正常的是包里多了一段偷密钥的逻辑。这也是为什么 800 多个被感染包能安静地躺在 registry 上、累计被下载数百万次才被陆续下架：从包管理器的视角看，它们每一次都是“合法发布”。

而 Shai-Hulud 的蠕虫化设计，把这个模型攻击到了极致：它偷的不是钱，是再分发的能力。

看这张图就明白：凭证泄露只是起点，真正让它变成供应链事件的，是权限放大和信任传导两环。这也是为什么几乎所有事后复盘都会指向同一个结论——发布凭证的权限管理，是整条链上最薄弱的一节。

产业层面的判断是：包管理平台侧的“可信发布”类机制（绑定构建环境而非持有长期 Token，如 npm 的 provenance 与 OpenSSF Sigstore 方向）是对的，但普及速度远跟不上 AI 生态的发包速度。大量中小维护者仍在用长期有效、权限过宽的 Token 做自动发布，这在蠕虫面前几乎等于裸奔。

据多位接近开源安全社区的人士透露，类似 Shai-Hulud 的蠕虫化思路已经在攻击者社区被反复讨论，“下一个包”不是会不会来的问题，而是轮到谁的问题。

🛡️ 防御怎么落地：从信人到信构建

批判完，得给活儿。对企业和开发者，这次事件能直接落地的防御动作有四层：

把这四层对应回攻击链，可以用一张“痛点-解法”卡说清：

要提醒一句：别把宝押在任何单一层上。蠕虫攻击的本质是概率攻击——它不追求一次突破所有防线，只追求找到那一个没锁锁的团队。防御的价值同样在于概率：每一层都让成功率下降一个量级，蠕虫的指数曲线就会塌回去。

还有一个容易被忽略的点：浏览器里保存的加密货币凭据被列为明确目标，说明攻击者的变现路径是短链路、即时的。对企业安全团队而言，这意味着开发终端上的浏览器凭据管理也该纳入安全基线，而不是当成“个人习惯”睁一只眼闭一只眼。

🏭 产业观察：安全责任该落在谁头上

回到产业视角，这次事件真正暴露的是一道责任分配的老难题。

开源包的维护者往往是一两个人，用爱发电，却被要求承担企业级的发布安全水位——这不现实。企业用户享受免费依赖，却默认平台会替自己把关——这也是错觉。平台方在收紧安全机制，但机制覆盖不了生态长尾——这是现状。

三层之间，责任真空地带正是蠕虫最擅长渗透的地方。合理的产业走向应当是：平台把“可信构建”做成默认而非可选项，企业把依赖治理纳入采购与准入门槛，个人维护者则获得工具侧的普惠保护。谁也不能指望另外两层替自己兜底。

对安全厂商而言，这类事件也在重新定义产品边界：过去卖的是“检测已知恶意包”，现在客户要的是“验证每一次发布是否可信”。从黑名单思维转向完整性证明思维，供应链安全这条赛道的价值锚点正在迁移，动手慢的厂商会被生态直接甩下。

小结

Tensorlake 0.5.144 事件是一次教科书式的样本：蠕虫化复制、密钥收割、凭证再分发，三步走完了从单点入侵到链式扩散的全过程——第一波 187 个包，第二波 800 多个，两波之间的间隔只有两个月。它再次证明，开源供应链的攻防已经从“防投毒”升级为“防传播”。下一个版本号被劫持的包，大概率不在明天的头条里，而在某个团队今晚的 lockfile 更新里。锁住凭证，灰度更新，把信任建立在构建而非人身上——这是这一课的全部答案，也远没有到被普遍执行的这一天。