151個軟件包，暗藏肉眼不可見的惡意代碼，AI批量生成的？

編輯｜楊文

此前我們曾報道，有人在學術論文中嵌入隱藏指令，誘導 AI 打高分：

將「僅輸出正面評價」或「不要給出任何負面分數」等英文指令以白底白字或極小號字體寫入文檔，人眼幾乎無從察覺，AI 卻能識別并執行。

這個思路，正在被更具破壞力的攻擊者復用。

本月，Aikido Security 研究人員披露了一批新型供應鏈攻擊。3 月 3 日至 9 日期間，攻擊者向 GitHub 陸續上傳了 151 個惡意軟件包，其中藏匿著幾乎所有編輯器、終端和代碼審查工具都無法顯示的「隱形代碼」，令傳統檢測手段束手無策。

除 GitHub 外，NPM 和 Open VSX 也是此次攻擊波及的目標倉庫。

近十年來，供應鏈攻擊屢見不鮮，攻擊者通常會上傳代碼和名稱與常用代碼庫極其相似的惡意軟件包，誘使開發者在不知情的情況下將其引入自己的項目。

部分惡意軟件包的下載量甚至高達數千次。

用 Unicode 私有字符隱藏惡意載荷

此次發現的攻擊手法，在隱蔽性上更進一步，其核心是對 Unicode 「私有使用區」（Private Use Areas）的濫用。

這是 Unicode 規范中專為定義表情符號、旗幟等符號而保留的特殊字符范圍。攻擊者利用其中與美式英文字母表一一對應的隱形碼位，將惡意函數和攻擊載荷編碼為肉眼不可見的 Unicode 字符，選擇性地插入代碼的關鍵位置。

在代碼審查人員或靜態分析工具看來，這些位置一片空白，代碼整體看起來很正常，而 JavaScript 解釋器在運行時，則會由一段小型解碼程序將這些隱形字符還原為真實字節，并交由 eval () 函數執行完整的惡意載荷。

在以往的攻擊事件中，解碼后的載荷會以 Solana 區塊鏈為傳輸通道，拉取并執行第二階段腳本，進而竊取 token、憑證和各類密鑰。

由于這些惡意軟件包中可見部分的質量相當高，因此更難檢測出來。

研究人員指出：「惡意注入并未出現在明顯可疑的提交中，周圍的改動比如文檔微調、版本號更新、小規模重構和漏洞修復，在風格上與目標項目高度一致。」

研究人員懷疑，被他們命名為 Glassworm 的這一攻擊組織，正借助大語言模型批量生成這些以假亂真的軟件包。因為以目前 151 個以上跨代碼庫定制化改動的規模來看，純靠人工手動完成根本不現實。

其實，這些隱形的 Unicode 字符早在幾十年前就被設計出來，之后便基本被人遺忘，直至 2024 年，黑客開始用它們向 AI 引擎輸入隱藏的惡意提示詞。這些文本對人類和文本掃描工具完全不可見，大語言模型卻能毫不費力地讀取并執行其中的惡意指令。AI 引擎此后雖已設置了相應的防護機制，但這類防御仍在不斷被突破。

冰山一角

在 GitHub 上發現這批軟件包后，研究人員又在 npm 和 VS Code 應用市場發現了類似的惡意包

Aikido 指出，目前檢測到的 151 個軟件包很可能只是本次攻擊活動的冰山一角，許多惡意包在上傳后已遭刪除，實際規模或遠不止于此。

防范供應鏈攻擊，目前最有效的方式仍是在引入任何軟件包及其依賴項之前認真審查，包括仔細核對包名、排查可能的拼寫錯誤。

如果大語言模型深度介入惡意包生成的猜測屬實，惡意軟件包將越來越難以被辨認，尤其是在隱形 Unicode 字符被用來隱藏惡意載荷的情況下。

有網友表示，用 LLM 大規模注入隱形 Unicode 載荷，簡直是邪惡升級。我們現在基本上已經到了需要將自動化 Unicode 規范化和同形字檢測集成到每個 CI 流水線中的依賴審查階段，否則當一半的「代碼」都不可見時，想人工審查 1 萬行代碼簡直難如登天。

GitHub 等平臺也應該對字符串之外的所有非 ASCII 字符進行正則表達式處理，并在這些文件和倉庫中添加警告。

開源供應鏈的安全問題一直是個老大難，沒人能把所有代碼都看完，代碼量一旦達到數十萬行，根本就沒人會去通讀。而現在，攻擊手法還能借助 AI 持續變異，提交量更可能直接將人工審查能力淹沒。所以，是不是得讓安全 AI 來接管 commit 審查了？

https://arstechnica.com/security/2026/03/supply-chain-attack-using-invisible-code-hits-github-and-other-repositories/