开发者向模型询问, 帮其写一个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复制粘贴到终端的时代里, 流程正演变成最后一道防线, 可是这道防线当前几乎处于缺席的状态。