8年心血差点“一夜清零”！只因“自己人”装了个龙虾，4个核心仓库被投毒

kingfirefly

在开源生态高度繁荣的今天，一行代码、一个权限、一款插件，都可能成为引爆供应链安全危机的导火索。本文作者亲历了自己维护 8 年的知名开源项目 Neutralinojs 遭遇恶意攻击，且他的经历并非个例，而是一个典型信号：供应链攻击已经从“攻击代码”，演变为“攻击信任关系”。它不再依赖传统Bug，而是潜伏在协作者权限、开发流程乃至 AI 插件生态之中，悄无声息地发生。
原文链接：https://levelup.gitconnected.com/my-8-year-old-open-source-project-was-a-victim-of-a-major-cyber-attack-24af7eb3a82b

作者 | 

Shalitha Suranga

       编译 | 郑丽媛
出品 | CSDN（ID：CSDNnews）很多时候，我们总是担心想象中的风险，却很少直面现实中的恐惧。可当你最担心的事以完全意想不到的方式发生时，你该如何应对？
最近，我就亲身经历了这一切。我在 GitHub 上维护的一个热门开源项目，卷入了一场大规模软件供应链攻击。而这次被攻破的原因非常特殊 —— 竟是我们开发工作流里的一个Bug。
如果你也是开发者，那么这种事情完全有可能发生在你身上。运气差一点，你耗时十年的心血可能在一天之内毁于一旦，项目口碑也会彻底崩塌，再也无法挽回。
下面，就是我开源生涯中最惊险的一次事故，以及我是如何在安全团队和一点点“运气”的帮助下，救回这个 8 年老项目的。

项目背景：一个对标 Electron 的轻量级方案
这个项目叫 Neutralinojs。它是一个轻量级的跨平台桌面应用开发框架，2018 年我和其他几位开发者一起启动了这个项目，但很快就变成了我一个人维护。
过去几年，我投入了大量时间打磨这个项目，并逐步建立起社区生态，它曾三次入选 Google Summer of Code（GSoC）：2022、2024、2026 年。
简单来说，它的定位就是：Electron 的轻量替代方案。如今已有成千上万的跨平台应用基于它构建，开发者社区还在持续壮大，核心贡献者也一直在积极推动项目迭代。
这个项目一直强调两件事：极简设计和性能优先。对于很多程序员来说，Neutralinojs 不仅是工具，更是一种工程理念。

灾难的开始：一条 LinkedIn 私信
我平时不怎么刷 LinkedIn，但会认真查看私信 —— 很多人会来咨询 Neutralinojs、GSoC，或是邀请我参加技术分享。
3 月 5 日早上，我收到了一条来自 OpenSourceMalware（OSM）安全团队成员的 LinkedIn 私信。内容大概是：

“你的主代码仓库已经被植入恶意 JavaScript 代码，我们已经提交了一个 PR 用于清除它。”

看到这条消息，我整个人直接懵了。因为我最担心的事情就是：自己误合并了带恶意代码的 PR，所以甚至连 GitHub Dependabot 自动生成的 PR，我都会仔细 review。
我的第一反应是：我的 GitHub token 被盗了？还是账号被入侵了？但我对安全一向很谨慎，自认账号几乎不可能出问题。
但很快，我就确认代码库是真的被入侵了：项目四个核心仓库全部被注入恶意 JavaScript 代码。而且攻击手法非常隐蔽：这些恶意代码经过重度混淆，还利用大量空格巧妙隐藏，在 GitHub 代码查看器里，肉眼几乎无法察觉异常。
显然，这不是普通攻击，这是精心设计的供应链攻击。我立刻和 OSM 成员协作，第一时间保障贡献者、应用开发者和用户的安全。

紧急止血：第一时间做了什么？
虽然当时还不清楚这段恶意代码的破坏力，但我直接按最高危漏洞处理：
（1）合并 OSM 的 PR，清理所有仓库中的恶意载荷；
（2）删除已构建的 nightly 版本，禁用 nightly 构建工作流；
（3）吊销我之前创建的所有 GitHub Token；
（4）禁止所有受影响仓库默认分支的直接推送—— 这正是我们 Git 工作流里最致命的漏洞！
（5）检查 GitHub 发布历史和 NPM 包（@neutralinojs/neu、@neutralinojs/lib）；
（6）在所有受影响仓库添加重大安全公告，并通过 Discord 高优先级消息通知社区；
（7）启动全面安全审计：检查代码、活跃 Fork、仓库设置、GitHub Actions、开发工具等所有关联环节。
以上这些的核心目标只有一个：阻止恶意代码继续扩散。
根据 OSM 的报告 + 我的分析，最终结论如下：

• 攻击发生在 3 月 2 日很短一段时间内；
  
• 只有 Neutralinojs 组织下的 4 个仓库被强制推送、篡改历史 Git 提交，其他仓库安全；
  
• 所有 GitHub 发行版和 NPM 包都是干净的；
  
• 只有在 3 月 2–5 日之间 pull 代码的人可能中招；
  
• 攻击源头来自朝鲜，恶意代码会连接 C2（指挥控制）服务器（部署在 Vercel，已被移除）。
  

换句话说：这是一场差一点就炸掉整个生态的攻击！

幸运的是，在 OSM 团队支持下，我通过清理 Git 记录、开启 GitHub 分支保护规则，彻底解决了这次危机。

破案时刻：真正的入侵路径
尽管如此，但事情还没结束，我开始化身“侦探”，继续调查这件事情的源头：攻击者居然还能访问其他仓库（虽然主仓库已经禁止直接推送），这到底是怎么做到的？
我一开始以为是自己的某个 GitHub Token 被盗，但事实并非如此。我发现：注入恶意代码的强制推送，来自 Neutralinojs 组织非常早期的一位“老成员”，而且他的 GitHub 账号竟然还拥有所有仓库的写入权限！
我立刻吊销了他的权限，重新检查所有仓库，并同步给 OSM 团队。
随后，我在他的个人 GitHub 仓库里也找到了同款恶意 JavaScript 载荷——真相大白：是他的账号被攻陷了，不是我的 Token 或账号泄露。
我马上联系他，他回复：

“我刚装了 OpenClaw，还给了 GitHub 权限，可能就是这个原因。”

事后，OSM 发布了最终报告，重新扫描所有仓库后确认：Neutralinojs 代码库已完全安全。我也同步通知了所有贡献者，并给可能受影响的开发者提供了修复方案。
一天后，这位账号被黑的“老成员”确认：他是最近名为 ClawHavoc 供应链攻击的受害者之一，病毒通过被入侵的 OpenClaw 插件扩散。目前，同款恶意 JavaScript 载荷仍在通过其他被盗账号在 GitHub 上扩散，并且出现了多个变种。
据 OSM 披露：该恶意软件会从区块链交易中获取 C2 服务器地址。即便主服务器被 Vercel 下架，攻击者依然可以新建服务器，并把地址写入区块链，继续控制受害者电脑。

给所有开源维护者的安全建议
根据 OSM 的说法，这类跨平台、基于 JavaScript、利用区块链获取 C2 地址的供应链攻击正在快速激增，用 Linux / Mac 也并不代表 100% 安全。
我认为，以下是保护你自己和项目的关键建议：
（1）立刻开启分支保护规则，这是做正经项目的第一步；
（2）永远不要让 Git 明文存储 Token，Linux 下可以用 libsecret 安全存储凭证；
（3）定期检查仓库写入权限，前成员离开立即回收权限；
（4）谨慎选择依赖，下载前先看安全警报；
（5）仔细阅读所有依赖的更新日志与安全说明；
（6）最小权限原则，不要无脑给全量权限；
（7）不要盲目复制粘贴网上代码，尤其是终端命令；
（8）所有重要账号（GitHub、NPM 等）务必开启 2FA。
在此之前，我不是没见过病毒、木马、社会工程学等攻击，但这种形式的供应链攻击还是第一次亲身经历——现在的恶意软件已经进化到恐怖的程度：你只需要执行一条 git clone、npm install，甚至只是把某人加进仓库协作，电脑就可能中招。
2026 年，数字世界的每一步操作都要小心。供应链攻击，已是这个时代开发者最可怕的敌人。
同时也要谨慎使用 AI，使用前必须花时间了解它的工作原理。在我看来，OpenClaw 的插件生态设计非常“危险” —— 居然把原始系统命令存在 Markdown 文件里来扩展 AI 能力！
这一次，是 OSM 团队救了 Neutralinojs。现在项目所有仓库已经完全干净，我们将继续冲击 2026 年 GSoC！

疯了吧

说依赖AI插件生态就危险有点牵强，就像说用菜刀就可能切到手，文中那老成员是被OpenClaw插件坑了，但插件本身没问题，是账号被黑，这锅AI不背

gzcom520

龙虾的突然“繁荣”全部是tx和阿里的推手啊，全都是买的流量

922b3eb6

@元宝 这是openclaw的某个插件有安全漏洞还是openclaw本体有安全漏洞

温馨阁

多年的权限体系一次全放开

cjlcjl

龙虾是木马病毒，是敌人窃取机密，窃取资料的手段，醒醒吧，信息安全意识应排第一位，现在打仗打的是全方位的，其中Al战，信息战也是战争中的一种。

oppledr

插件投毒，智能体会越来越有危害性。智慧恶魔诞生了。

waluheke

谢谢分享~