Shai-Hulud npm 蠕虫对 dsh 用户意味着什么

发生了什么

根据 Wiz 的分析，攻击者利用被攻陷的维护者身份发布了恶意版本的 keyv，随后借助正常的 GitHub Actions 工作流蔓延到 400 多个包，这些包合计每月被下载约二十亿次。

最该让 agent 用户警惕的是第六波。它的载荷藏在 AI agent 配置文件里——没有哪个常规扫描器会去读这类文件。命令控制走的是以太坊智能合约，而不是一个可以被查封的域名。它还带着一个监视器：防守方一旦试图轮换被盗凭证，就立刻触发攻击者控制的代码。

为什么这会落到 dsh 头上

dsh 插件 = 一个 npm 包 + cordis.yml 里的一条配置。安装它会跑完 npm 的整套机器——安装脚本、传递依赖、lockfile 没钉死的一切——然后把结果加载进那个握着你的 API 密钥、跑着你的 shell 的进程。Shai-Hulud 用过的每一种机制，在这个生态里原封不动地存在。

最值得记住的细节：载荷藏在 agent 配置文件里。在 dsh 里，加载器配置就是攻击面——cordis.yml 决定什么代码进入进程。一个大多数人从 README 里复制粘贴、从来不读的文件，正是这类攻击最好的藏身之处。

有 dsh 插件中招了吗？

目前没有人拿出实例。截至发稿（2026 年 8 月 18 日），在我们索引的 1805 个仓库里，没有已证实的恶意包。但这个 topic 是无人审核的开放标签，生态才诞生几天，而上面那场 npm 攻击在 dsh 发布前两周就已经在进行中。这么早没出确证案例，不能当作安全的证据。

当一个条目带有可核实的警示信号——与更高人气仓库只差一次编辑的名字、藏在短链后面的主页、让你把下载内容用管道送进 shell 的描述——我们会把这个事实印在条目页上。我们不下结论；仓库元数据支撑不了结论。

实际该做什么

钉死你审查过的确切版本，提交 lockfile，试新插件的环境里不要放生产凭证。往 cordis.yml 里加任何东西之前，过一遍完整的审查清单。如果你在我们索引的仓库里发现恶意内容，向我们举报——确证案例会被移出目录。