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审查了？