开发者向模型询问, 帮其写一个REST API示例, 模型生成了一段看上去颇完整的代码, 有, 有pip rest -, 甚至还有注释对每个依赖的用途予以说明, 开发者进行复制粘贴, 于终端运行了一遍pip, 一切正常, 只是存在一个细节。
rest-这个包名不存在。真实安装包是。
假设这仅仅是一回运行之际出现报错, 其实不算什么重大事情。然而你可曾思考过: 要是存在有人于PyPI之上预先注册了rest这个名字, 并且在其中填充了恶意代码, 那么会出现怎样情况呢?
这称作某种情况, 与传统方式——也就是依赖拼写错误——不一样, 所赌的内容是, AI模型能够稳定无误地“编造包名”。这并非是寄希望于你偶然手滑敲错一个字, 而是笃定模型在每一次都会犯下同一个错误。
在2026年5月的时候, 有一位独立研究者, 发表了一篇论文, 这篇论文复现并且扩展了之前在2025年的研究。这位研究者测试了五个前沿代码模型, 分别是4.6、Haiku 4.5、GPT - 5.4 - mini、2.5 Pro、V3.2 , 在20万次代码生成当中, 他去检查代码里是不是引用了不存在的PyPI或npm包。那么结论非常直接, 这五个模型共同幻觉出了127个包名, 其中有53个包名仍然能够被攻击者所注册呢。
不是单一某个模型存在幻觉方面的问题, 是全部前沿模型都在一块儿犯下同一批错误。并且这个所谓的“共同错误集”, 正逐渐演变成一个跨越模型范畴的供应链攻击面临的状况面。
并非是幻觉, 乃是“合理外推”, 那为何AI会编出听起来相当靠谱的包名呢?
这些幻觉包名有一个共同特征：它们看起来太正常了。
“aws-cdk”, 貌似是AWS CDK的包, 可实际上真正的包名是aws-cdk-lib。“”, 好像是那个安装包, 然而真实的包却被拆分成了-api和-sdk。“”, 看似是腾讯云SDK的包, 实际其真实包名是-sdk-。“”, 看上去是那个SDK包, 可实际上发布名是。
这些名字具备这样的共同特征, 语义是正确的, 命名习惯契合所在生态的规范, 且和真实包极为接近。它们并非随机产生的乱码。模型可不是在“胡说八道”, 它是在进行“合理外推”。
原因存在两个, 第一个是, 共享训练语料之中存在错误信号, 大量教程、博客以及Stack回答里, 模块名、项目名和安装包名被混用, 代码里能够写, 这是合法的语句, REST确实会暴露这个模块名, 然而安装时应该采用pip, 模型并不理解这个区别, 它在语料里反复见到“REST”这个概念, 又看到包常常通过dash连接, 于是补全得出pip rest-。
第二个情况是, 存在命名空间规则过度泛化的现象。在npm生态里, 有@ember/、@ember/, 这些属于Ember.js框架内部模块, 其会随着ember一起打包, 并非能够独立安装的包。然而呢, 模型它看到@scope/name这样的模式时, 就作出推断, 觉得它们应当和@/core一样是能够独立安装的。
这其中的关键并非是模型, 它并非“不够聪明”。而是在模型的工作方式与包注册表的运作方式之间, 存在着一个根本性的错位情况。其中, 模型是通过概率分布生成出最可能的包名。而包注册表则是按照先到先得的原则来注册包名。模型并不清楚一个名字是否已经被注册, 是否根本就不存在, 又是否是今天刚被攻击者抢注。它仅仅会依据训练数据输出它觉得最合理的名字。
而"最合理"不等于"真实存在"。
反而比更危险：Agent场景让问题升维
论文里, 有一个值得予以留意的颇为反直觉的发现, 即, 包名的幻觉率是较高于某一对象的, 并且, 这样的一种趋势, 是出现在所有的五个模型之上的。
在先前的研究里头, 更易于出现问题, npm生态更为庞大, 包名更加碎片化, 且更为猖獗。然而2026年的这批前沿模型却反过来了, 其幻觉率比高出2.73至4.13个百分点。
这对于企业安全来讲, 是一个相当重要的信号, 因为企业引入AI最先实现落地的场景, 恰恰大多是这些, 数据分析脚本, 自动化运维脚本, 后端, 安全运营工具, 模型评测流水线, 这些场景的代码数量通常不算多, 开发者更为习惯直接去复制模型所给出的安装命令, 要是企业不存在依赖校验, 那么每一个pip都极有可能构成一次供应链投毒。
更为严重的是, Agent场景。人类开发者在复制pip之前, 或许还会迟疑一番, 会思考这个名字是否正确。然而, AI Agent却不会有此迟疑。要是Agent具备shell、包管理器以及CI权限, 那么pipp xxx便会从“建议”转变为“动作”, 即直接执行, 期间不存在人类进行最后的审核。
那篇论文所提及的攻击链竟是这般容易理解: 有攻击者, 其大量地去询问代码模型, 从而收集模型常常生成的并没有存在的包名。彼时, 攻击者将这些包名注册到PyPI或者npm。紧跟着, 开发者朝着模型提出与之相类似的需求。之后, 模型生成引用那个仿若真实却实际不存在的包名的安装命令。接着, 开发者或者自动化Agent依照这个命令去安装该包。最终使得恶意代码于开发环境、构建环境乃至生产环境里头执行。
走在这条链路之上, 攻击者没必要去侵入模型厂商, 没必要让训练数据遭到污染, 没法先行和面向对象, 目标开发者进行任何接触。仅仅只是具备注册包名的能力, 接着静候模型把用户引领到设置的地方。攻击所需投入的成本, 无限趋近于零, 覆盖的范围取决于模型出现错误的稳定性程度如何。
而论文证明，它们非常稳定。
跨模型共同幻觉：127个名字，5个模型都在编
对于这篇论文来讲, 最为重要的发现并非是某一个模型的幻觉率究竟是高还是低, 而是“跨模型共同幻觉集”这样一个概念。
有五个模型一同产生了幻觉, 涉及到了127个包名, 其中18个包名归属于npm, 在经作者披露给PyPI和.dev审查判定确定之后, 仍存在109个从PyPI而来的包名, 并且还有53个包名能够被攻击者进行注册, 这其中41个是来自PyPI的, 另外12个是来自npm的。
选取相似度来进行估算衡量, 10组模型对形成的相应平均值是0.222。其中数值最高的那两个, 即是V3.2与GPT-5.4-mini , 它们二者所达到的具体数值为0.343。对于此情况, 作者并没有去明确断定两者之间存在训练数据方面的关系 , 仅仅只是表示其有可能来源于共享语料 , 或者是存在相似的生成偏差。
那这对于安全评估而言究竟意味着些什么? 企业以往进行AI安全评估的时候, 所关注的要点是: 其这个模型的幻觉率到底高不高? 其这个模型生成危险代码的比例到底高不高?
从特定的视角去看, 还需要提出另外一个问题, 众多不同的模型会不会将同一批对象判断错误呢?
倘若每个模型皆有误, 然而所错之处存有差异, 那么攻击者便需分别予以适配。要是多个模型于同一批包名上出错, 那么这批包名便具备跨模型复用之价值。而攻击者注册一个名字, 同时涵盖了、GPT、以及四个生态的用户。ROI呈指数级放大。
这项研究的局限是相当明晰的: 仅仅对裸模型输出进行了测试, 未涵盖带有联网检索的情况, 也未涉及带有企业依赖门禁的完整 AI 产品链路。要是代码助手在生成依赖之前能够联网去查询 PyPI/npm, 又或者在执行之前存在某种情况, 那么风险将会显著降低。
但实际情况是, 当下多数AI产品并不具备这种能力, 模型直接输出依旧是默认的工作模式, 在依靠验证这点上, 行业整体的成熟程度远远落后于AI编程工具的普及速率。
门禁不是在代码里，是在流程里
凭工程落地的角度来讲, 防靠提示词是不行的。“请不要编造不存在的软件包”这样的指令是有一定作用的, 然而却不能当作主要防线。模型自身并不是实时包注册表, 它没办法知晓某个包名在当下是不是存在, 是不是才刚被注册, 维护者是否可靠。
更为稳妥的做法是, 将AI生成的依赖统一纳入到供应链安全门禁之中。在生成阶段, 要实时查询PyPI/npm；在Agent执行阶段, 需拦截所有的包管理器命令；在CI/CD阶段, 要对AI引入的新增依赖进行强制审计。
这并非是那种甚为高深的安全技术, 它仅仅是一种流程而已, 然而在一个当中越来越多的人直接将AI所生成的pip复制粘贴到终端的时代里, 流程正演变成最后一道防线, 可是这道防线当前几乎处于缺席的状态。
