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

編輯｜楊文

此前我們?cè)鴪?bào)道，有人在學(xué)術(shù)論文中嵌入隱藏指令，誘導(dǎo) AI 打高分：

將「僅輸出正面評(píng)價(jià)」或「不要給出任何負(fù)面分?jǐn)?shù)」等英文指令以白底白字或極小號(hào)字體寫入文檔，人眼幾乎無從察覺，AI 卻能識(shí)別并執(zhí)行。

這個(gè)思路，正在被更具破壞力的攻擊者復(fù)用。

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

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

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

部分惡意軟件包的下載量甚至高達(dá)數(shù)千次。

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

此次發(fā)現(xiàn)的攻擊手法，在隱蔽性上更進(jìn)一步，其核心是對(duì) Unicode 「私有使用區(qū)」（Private Use Areas）的濫用。

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

在代碼審查人員或靜態(tài)分析工具看來，這些位置一片空白，代碼整體看起來很正常，而 JavaScript 解釋器在運(yùn)行時(shí)，則會(huì)由一段小型解碼程序?qū)⑦@些隱形字符還原為真實(shí)字節(jié)，并交由 eval () 函數(shù)執(zhí)行完整的惡意載荷。

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

由于這些惡意軟件包中可見部分的質(zhì)量相當(dāng)高，因此更難檢測(cè)出來。

研究人員指出：「惡意注入并未出現(xiàn)在明顯可疑的提交中，周圍的改動(dòng)比如文檔微調(diào)、版本號(hào)更新、小規(guī)模重構(gòu)和漏洞修復(fù)，在風(fēng)格上與目標(biāo)項(xiàng)目高度一致?！?/p>

研究人員懷疑，被他們命名為 Glassworm 的這一攻擊組織，正借助大語言模型批量生成這些以假亂真的軟件包。因?yàn)橐阅壳?151 個(gè)以上跨代碼庫定制化改動(dòng)的規(guī)模來看，純靠人工手動(dòng)完成根本不現(xiàn)實(shí)。

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

冰山一角

在 GitHub 上發(fā)現(xiàn)這批軟件包后，研究人員又在 npm 和 VS Code 應(yīng)用市場(chǎng)發(fā)現(xiàn)了類似的惡意包

Aikido 指出，目前檢測(cè)到的 151 個(gè)軟件包很可能只是本次攻擊活動(dòng)的冰山一角，許多惡意包在上傳后已遭刪除，實(shí)際規(guī)模或遠(yuǎn)不止于此。

防范供應(yīng)鏈攻擊，目前最有效的方式仍是在引入任何軟件包及其依賴項(xiàng)之前認(rèn)真審查，包括仔細(xì)核對(duì)包名、排查可能的拼寫錯(cuò)誤。

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

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

GitHub 等平臺(tái)也應(yīng)該對(duì)字符串之外的所有非 ASCII 字符進(jìn)行正則表達(dá)式處理，并在這些文件和倉庫中添加警告。

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

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