装完一个软件包，自己的软件也被投毒：回看npm自传播蠕虫

安装一个名字熟悉的软件包，麻烦却可能变成“自己维护的软件也被发出了恶意更新”。2025年9月中旬，Shai-Hulud蠕虫在JavaScript软件包生态npm中传播。GitHub随后在9月22日的公告里确认，已移除超过500个受污染的软件包。这轮攻击把受害者和传播者之间的界线打乱了。

npm可以理解成程序员的零件市场：网站和应用不必从零写起，能直接安装别人维护的代码。便利的另一面是，一次安装可能包含许多间接依赖。用户认得的项目名称没有变化，并不代表后来发布的每个版本都经过同样可靠的控制。

StepSecurity的分析解释了这条链如何闭合：恶意安装脚本在开发环境中寻找发布凭证，拿到权限后，又把恶意代码加入该维护者有权发布的其他软件包，再发布新版本。于是受害者不只是被偷东西，还可能无意中成为下一批受害者的供货商。像一家零件店收到污染货品，连仓库钥匙也被拿走，随后其他货架被一起换货。

还有一个反转：Socket发现，恶意程序借用了本来帮助开发者查找泄露密钥的开源工具TruffleHog。工具没有变成恶意软件；攻击者改变了它的用途，把“找出应该保护的秘密”变成“找出值得偷走的秘密”。这与破解所有密码不同，目标是环境中已经存在、能够被访问的凭证。

损害也不限于软件发布。Wiz在初期调查中观察到，八名用户的私有代码仓库被复制、转为公开；另一些凭证被放进公开仓库。这是研究者当时看到的范围，不能当作事件最终总数。即使删除恶意更新，也不能让已经公开的数据自动恢复秘密状态。

供应链投毒、安装脚本被滥用都不是新发明。CERT/CC把它们追溯到更早案例；Wiz将这次事件称为npm生态中首次成功的自传播攻击。这次的变化，是偷凭证、修改合法软件包、再借安装取得更多凭证组成了循环，而不是黑客又换了一封钓鱼邮件。

因此，处置不只是卸载一个包。CERT/CC建议撤销并更换可能暴露的凭证，缩小发布权限，并隔离构建环境，避免不受信任代码接触发布凭证。这些措施分别切断盗用旧权限和污染下一批软件的机会；它们并不意味着每个npm用户都已感染。

这起旧事件留下的问题仍然具体：安装软件的地方，是否也放着发布软件的钥匙？读入外部代码和向外发布代码，本是两种不同责任。当它们共享权限，一次普通依赖更新就可能越过原本只属于维护者的边界。

首轮事件公开分析：2025年9月15日起。