8年心血差點“一夜清零”！只因“自己人”裝了個「龍蝦」，4個核心倉庫被投毒

在開源生態高度繁榮的今天，一行代碼、一個權限、一款插件，都可能成為引爆供應鏈安全危機的導火索。本文作者親歷了自己維護 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！