AI供应链"幻觉蹲守"攻击升级：5模型共享127个虚构包名

duckwolf

2026年7月19日，安全社区曝光的最新研究显示：即使在GPT-5.4-mini、Claude Sonnet 4.6、Claude Haiku 4.5、Gemini 2.5 Pro、DeepSeek V3.2这五大前沿代码模型上，"包名幻觉"（package hallucination）依然以4.62%-6.10%的概率发生。更危险的是，研究识别出127个包名（109个PyPI + 18个npm）被五大模型同时虚构，其中53个在现有防御机制下仍可被攻击者注册。这是"AI供应链投毒"从理论威胁升级为实战威胁的标志性事件。


一、Slopsquatting：AI供应链的新攻击面

Slopsquatting（直译"废物命名蹲守"）这一概念由Python软件基金会开发者驻场Seth Larson命名，专门描述一种新型供应链攻击：

攻击链路：
1. 攻击者用同一提示词大规模查询LLM，记录模型虚构的包名
2. 在PyPI/npm上抢注这些不存在的包名
3. 包内植入setup.py/postinstall钩子/malicious module
4. 等待开发者运行pip install / npm install，恶意代码以开发者身份执行
5. 窃取CI/CD凭证、云SSO会话、云CLI token、私有仓库访问权限

为什么这种攻击几乎无解？
• 攻击成本：注册一个PyPI/npm包零成本
• 攻击时机：包名一旦注册就持续存在，等待任何一个受害者
• 攻击规模：一次注册，全球任何使用同款AI编程助手的开发者都可能中招


二、关键数据：5.2%到21.7%的虚构率

USENIX Security 2025论文（Spracklen等，弗吉尼亚理工+俄克拉荷马大学+UTSA）首次量化了这一威胁：
• 总样本：576,000个Python和JavaScript代码样本
• 覆盖模型：16个代码生成LLM
• 虚构包名总数：约205,000个唯一包名
• 平均虚构率：
• 商业模型（GPT-4 Turbo等）：5.2%（最低3.59%）
• 开源模型（CodeLlama等）：21.7%（最高33%+）
• 重复率：43%的虚构包名在10次重复查询中稳定出现，58%出现多次

2026年5月的新研究（arXiv:2605.17062）评估了5个前沿模型：
• GPT-5.4-mini：6.10%（最高）
• DeepSeek V3.2：5.20%
• Gemini 2.5 Pro：5.50%
• Claude Sonnet 4.6：5.00%
• Claude Haiku 4.5：4.62%（最低）

虽然平均率从21.7%降到5%左右，但127个跨5模型共享的虚构包名让攻击者可以用"一次注册、跨厂商通用"的策略。


三、TeamPCP：把理论攻击变成实战

2026年3-7月，一个名为TeamPCP的有组织威胁团伙，把Slopsquatting从学术研究推到了实战阶段：

3月24日：litellm攻击
• 目标：开源AI网关项目，月下载量9500万+
• 手法：通过入侵Trivy（Aqua Security）→ 窃取PyPI Token → 上传恶意版本1.82.7和1.82.8
• 后果：全平台凭证窃取 + K8s横向移动
• 标志：恶意版本在GitHub没有对应tag/发布

4月22日：xinference攻击
• 目标：XorbitsAI的LLM推理服务器，GitHub 9.3K stars
• 手法：通过被入侵的XprobeBot机器人账号上传恶意版本2.6.0/2.6.1/2.6.2
• 后果：base64混淆的恶意负载注入__init__.py
• 标志：正版最新版本仅2.5.0，2.6.x在GitHub端不存在

这两起攻击的共同特征：
• 攻击对象都是"AI基础设施"（litellm是网关、xinference是推理服务器）
• 攻击都通过"上游入侵+凭证窃取+下游投毒"的链式操作
• 攻击都瞄准"开发者本地环境"，以窃取CI/CD、云凭证、部署密钥为目标
• 攻击都利用了"AI开发者对依赖包的高度信任"


四、已确认的野生Slopsquatting攻击

除TeamPCP外，社区已经确认多起野生攻击：

1. huggingface-cli（2024年初）
• Lasso Security研究员Bar Lanyado注册了一个虚构包huggingface-cli
• 3个月内被下载30,000+次
• 阿里甚至把这个虚构的安装命令复制到了公开仓库README

2. react-codeshift（2026年1月）
• Aikido Security捕获的恶意npm包
• 是jscodeshift和react-codemod的"混淆幻觉"
• 通过237个仓库传播

3. unused-imports
• 同样的恶意npm包
• 每周233次下载时被npm标记

这些野生案例证明：Slopsquatting不是理论威胁，而是正在发生的供应链攻击。


五、对开发者的六个实操建议

1. 把AI推荐的包名当作"不可信输入"
• 在安装前先到PyPI/npm官方页面搜索，确认包存在、维护者有历史、下载量合理
• 警惕"AI推荐→一键安装"的工作流，这正是攻击者设计的入口

2. 用allowlist + 锁定清单
• 在CI/CD中维护一个"高敏感服务+生产Agent"的依赖白名单
• 使用npm ci（Node）或pip install --require-hashes（Python），把安装锁定到具体版本+哈希
• 拒绝任何在锁定清单外的依赖自动安装

3. 禁用安装时执行
• 在CI中使用--ignore-scripts（npm）或类似选项，禁用package lifecycle hooks
• 拆分构建任务：依赖解析在低权限环境执行，签名/部署在隔离环境执行
• 测试任务绝不暴露生产密钥

4. 优先使用Trusted Publishing
• PyPI和npm都支持Trusted Publishing，用短期OIDC凭证替代长期token
• 启用npm provenance，在工具链支持的地方验证attestations
• 内部发布使用artifact attestations，让下游系统验证构建来源

5. 强化人+Agent工作流
• 把所有AI推荐的包名当作"待审批输入"
• 对敏感仓库禁用"自动安装并执行"的Agent循环
• 在日志、提示词、生成的patches对外分享前脱敏

6. 监控生态警告
• 订阅PyPI Security邮件列表和npm安全公告
• 关注Snyk、Socket、Aikido、JFrog等供应链安全公司的告警
• 定期审计依赖图谱，发现可疑包立即隔离


六、对AI编程工具厂商的五个要求

1. 在生成代码时强制包名校验
• 当AI推荐一个不存在的包时，应主动警告开发者
• 集成PyPI/npm API实时验证包存在性

2. 提供"白名单依赖"配置
• 允许企业在团队级别配置"允许推荐的包名白名单"
• 默认拒绝推荐未经验证的新包

3. 强化安装路径管控
• 默认禁用Agent的"自动安装并执行"循环
• 把"安装"和"执行"分两步，每步都需要开发者确认

4. 公开幻觉率报告
• 像模型性能benchmark一样，定期公布包名幻觉率
• 让企业用户在采购时有可比性数据

5. 协同PyPI/npm建立黑名单机制
• 联合注册管理机构，对127个"跨模型共享虚构包名"建立预警库
• 当LLM推荐这些包名时主动拦截


七、对整个AI行业的三个判断

1. "AI供应链安全"将成为下一个独立赛道
• 类似云原生时代的Sigstore/Cosign/SLSA，AI编程时代需要新的供应链安全标准
• 预计Q4将出现首批"AI代码供应链安全"专业公司

2. 模型厂商的责任将受到监管关注
• 美国NIST、欧盟AI Act、中国《人工智能法（草案）》都可能将"包名幻觉率"纳入合规指标
• 头部模型厂商（OpenAI、Anthropic、Google、DeepSeek）将被迫公开相关数据

3. 企业AI开发的安全成本将上升
• 从"开发者自由使用AI编程助手"转向"白名单+审计+管控"
• 安全团队需要建立"AI生成代码"的专门审查流程

风险提示：Slopsquatting攻击已成为2026年AI编程工具的最大安全威胁之一。任何依赖AI生成代码的团队，都应立即审查现有依赖清单，建立"AI推荐包名校验"流程。已发生过的litellm、xinference等供应链攻击显示，攻击者已经形成"上游入侵+下游投毒"的成熟链路。本文仅作安全研究参考，具体防护方案应结合企业实际架构咨询专业安全团队。

数据来源：USENIX Security 2025论文（Spracklen等）、arXiv:2605.17062（Churilov 2026）、Python软件基金会Seth Larson公开声明、Lasso Security Bar Lanyado 2024研究、Aikido Security 2026-01公告、JFrog Security分析报告、奇安信CERT TeamPCP攻击分析、secrrs.com Xinference攻击报告。