文章总结： 文档披露npm与Maven供应链攻击。npm攻击利用老旧包变种窃取Token，自动注入其他包实现蠕虫传播。Maven攻击通过仿造GroupID，利用SpringBoot自动装配植入木马。建议开发者严格检查依赖ID、使用Lockfile锁定版本并监控流量，以防范供应链投毒风险。 综合评分： 90 文章分类： 供应链安全,恶意软件,漏洞分析,安全意识

恐怖的“沙虫”复活！npm 再次爆发蠕虫级投毒，连 Java 这里的 Maven 也失守了？

原创

Kit Chung

安全圈动向

2026年1月7日 07:51 广东

兄弟们，如果你今天刚刚执行完npm install 或者mvn clean install，建议你先停下手里的咖啡，听我讲个事儿。

我们做开发的，最怕的不是需求变来变去，而是你信任的“基石”——开源依赖库，背后来一刀。

最近，安全圈炸锅了。根据最新的研究报告，大名鼎鼎的 npm 和 Maven 仓库接连失守。一个是像电影《沙丘》里的巨型沙虫（Shai-Hulud）一样会自我繁殖的蠕虫变种，另一个则是利用 Java Spring Boot 特性进行的高智商伪装。

别以为这只是脚本小子的恶作剧，这次黑客展示的技术细节，甚至让我这个老司机都觉得：“这路子太野了”。

今天，咱们就扒开源码，看看这两起攻击到底是怎么通过我们的防御网的。

01 “沙虫”归来：npm 里的自我繁殖实验

还记得 2025 年 9 月那波代号为“Shai-Hulud”（沙虫）的攻击吗？当时它不仅窃取 Token，还利用这些 Token 疯狂发版。

就在上个月（2025 年 12 月 28日），研究人员发现这货变异了，又回来了。

潜伏四年的“老实人”突然黑化

这次的载体是一个叫 @vietmoney/react-big-calendar 的包。

最骚的操作在于，这个包早在 2021 年 3 月 就上传了，是一个叫 hoquocdat 的用户发布的。这就很具迷惑性——很多安全扫描工具对“老旧且未更新”的包会放松警惕。

然而，沉睡了 4 年多后，它突然更新到了 0.26.2 版本。Aikido 安全团队发现，这次更新并没有大范围扩散，下载量不到 200 次。种种迹象表明，黑客正在拿这个包做“灰度测试”。

技术拆解：它到底干了什么？

这次的变种代码经过了深度的二次混淆（Obfuscated），但我们还是能看到几个关键的技术升级：

1. 文件架构重构 入口文件伪装成了 bun_installer.js，核心 Payload 藏在 environment_source.js 里。它专门盯着你的敏感文件下手，比如 3nvir0nm3nt.json、cl0vd.json，甚至是 pigS3cr3ts.json（这名字也是绝了）。

2. 去掉了Dead Man Switch 在上一代版本中，如果脚本没找到可以利用的 GitHub 或 npm Token，它会直接执行 Wiper（擦除器）把受害者的文件删个精光。但这次，这个功能被移除了。

解读： 这进一步证实了这是测试版。黑客现在的目标是隐蔽收集，而不是破坏。他们想悄悄地进村，打枪的不要。

3. 蠕虫式供应链污染（核心逻辑） 这是最让我头皮发麻的地方。这个恶意代码不仅仅是偷你的 Token，它会武器化这些 Token。 一旦它拿到了你的 npm 发布权限，它会自动抓取你名下下载量最大的前 100 个包，把同样的恶意代码注入进去，然后自动发布新版本。

这就形成了一个闭环：你中招 -> 你的包中毒 -> 用你包的人中招 -> 无限循环。

02 Java 界的“狸猫换太子”：Maven 投毒案

如果说 npm 那边是“生化危机”，那 Maven 这边的案子就是一场精心策划的“特工潜入”。

那个 com 和 org 的陷阱

黑客在 Maven Central 上上传了一个叫 org.fasterxml.jackson.core/jackson-databind 的包。

看出来了吗？ 正版的 Jackson 库（Java 开发必备的神级 JSON 库）的 Group ID 是 com.fasterxml.jackson.core 黑客只是把 com 换成了 org。 除此之外，它还注册了一个高仿域名 fasterxml.org（正版是 .com）。

这利用了 Java 生态中“反向域名命名法”的一个盲区——Maven Central 并没有强制校验 Group ID 的所有权归属，这就给了李鬼可乘之机。

极客级的 Spring Boot 注入手法

这才是这个案例最精彩（也最危险）的技术点。这个恶意包并不是简单地写个 static 块那么简单，它完美利用了 Spring Boot 的自动化机制。

攻击流程解析：

• 依赖引入：

  当不知情的开发者在 pom.xml 里引入这个包。

• 自动装配（Auto-Configuration）：

  JAR 包里藏了一段恶意代码。当你的 Spring Boot 应用启动时，Spring 会扫描 @Configuration 注解。 黑客定义了一个类 JacksonSpringAutoConfiguration，并加上了 @ConditionalOnClass({ApplicationRunner.class})。 众所周知，ApplicationRunner 在 Spring Boot 里是标配。于是，检查通过，恶意 Bean 被注册。

• 静默执行：

  应用上下文（Context）加载完毕后，恶意的 ApplicationRunner 会自动执行。无需任何显式调用，你的代码只要跑起来，木马就进来了。

这里的“反侦察”意识

黑客甚至考虑到了开发者的环境。代码运行前会检查工作目录下是否存在 .idea.pid 文件。这是 IntelliJ IDEA 的特征文件。

• 如果存在，说明可能已经在运行了，为了防止重复运行暴露痕迹，它会静默退出。
• 如果不存在，它才会向 C2 服务器（m.fasterxml[.]org:51211）发起请求。

终极 Payload：Cobalt Strike

根据你的操作系统（Windows 下载 svchosts.exe，macOS 下载 update），它会释放一个 Cobalt Strike Beacon。 这意味着什么？意味着黑客不仅仅是想偷点数据，他们想把你的机器变成肉鸡，进行长期的后渗透攻击（Post-Exploitation）。

03 信任是最大的漏洞

看完这两个案例，不知道大家什么心情。我觉得最讽刺的是，这两起攻击利用的都是我们最习以为常的东西：开源社区的信任 和 开发框架的便利性。

我们该怎么办？

1. Lockfile 是保命符：无论是 package-lock.json 还是 yarn.lock，一定要提交到仓库。它能锁定版本，防止不明不白的自动升级。

2. 眼见为实：引入 Java 依赖时，别光看 Artifact ID，Group ID 必须核对清楚。com 变 org，一字之差就是天坑。

3. Scope 限制：对于不确定的包，利用 Scoped Packages（如 @myorg/package）是一种隔离手段。

4. 监控异常流量：那个 Java 的木马会去连 51211 这种非标端口，公司内网的防火墙策略如果不严，这就是直接的后门。

技术在进步，黑客也在进化。现在的攻击早就不是“乱拳打死老师傅”，而是盯着你的开发习惯下手。

转发这篇文章到你的技术群，提醒大家检查一下最近的 package.json 和 pom.xml。

安全无小事，别让自己辛辛苦苦写的代码，成了黑客手中的武器。

互动话题：

你在开发生涯中，遇到过哪些离谱的依赖坑？欢迎在评论区留言，说出你的故事！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈动向 Kit Chung《恐怖的“沙虫”复活！npm 再次爆发蠕虫级投毒，连 Java 这里的 Maven 也失守了？》