仓库不应为自己的信任投票

2026年4月24日，Anthropic发布了GHSA-q5hj-mxqh-vv77，这是一个CVSS评分7.7的Claude Code信任对话框绕过漏洞。37天前的3月18日，同一项目发布了GHSA-mmgp-wc2j-qcv7，CVSS评分相同。同一代理运行时在同一个六周窗口内出现两个信任对话框绕过漏洞，绝非巧合。¹²

共同的形态就是教训所在。在3月的漏洞中，项目控制的.claude/settings.json在工作区信任检查之前被读取，该文件中的bypassPermissions权限模式可轻易满足这道关卡。²在4月的漏洞中，恶意仓库在.git/内放置精心构造的commondir文件，信任评估器顺着指针指向用户已信任的目录，工作区便继承了该信任，对话框从未弹出。¹

仓库内两行文字，无人打开就足以让工作区被投票为受信。仓库附带的项目级各类配置（钩子、MCP服务器配置、技能、子代理）随后即可基于这一票被解析，无论是会话启动时主动加载，还是调用时延迟加载。任何代理运行时的下游防御，都受制于运行时在它们存在之前所做的决定。

TL;DR

• 37天内的两个Claude Code信任对话框绕过CVE，揭示了当仓库控制的字节影响工作区信任时，会发生什么样的崩溃。
• 用户侧的紧急修复方法是：升级至2.1.84以上版本、缩窄~/.claude.json中的受信路径，并避免授予~/Projects这类宽泛的父路径信任。
• 结构性修复是一条加载顺序不变量：在工作区路径被显式信任之前，不解释工作区的任何字节。

两份公告实际修补了什么

对照文档阅读补丁，加载顺序的失败一目了然。修复版本重新调整了信任评估器被允许读取哪些字节的顺序。

3月的公告描述了Claude Code在解析工作区信任之前先解析了项目设置。2.1.53中的修复颠倒了这一顺序，使信任检查在用户作出决定之前不再读取工作区内的.claude/settings.json。²4月的公告描述了信任评估器在解析工作区路径本身时，跟随了仓库.git/目录中的commondir文件。2.1.84中的修复阻止了评估器在信任评估期间采信仓库控制的commondir内容。¹两个补丁恢复了同一个不变量：信任决策不得读取存放在候选工作区内部的字节。

CVE分类指向同一个诊断结果。3月的漏洞归类为CWE-807，Reliance on Untrusted Inputs in a Security Decision。³4月的漏洞归类为CWE-20加CWE-77，Improper Input Validation与Improper Neutralization of Special Elements，因为commondir解析将仓库控制的字节视为权威。¹CWE不同，但破裂的假设相同：一道安全关卡却从它所守护的工件中读取信息。

信任前的攻击面比设置文档暗示的更广

Claude Code记录了一组项目控制的会话启动配置面，这些配置面必须始终位于信任关卡之后。本类的两个CVE证明，只要其中任何一项进入信任决策本身，不变量就会崩塌。这些配置面分为信任分析必须严格区分的两个范围：随克隆仓库附带的字节，以及用户在工作区本地添加但未提交的字节。⁴⁵⁶⁷

仓库提交的配置面（随git clone附带）。这些是供应链层面的攻击面。攻击者编写恶意仓库时，所能控制的就是这一组。

工作区本地配置面（默认不提交）。这些不会随供应链进入工作区；只有当本地用户创建时才会出现。它们仍然位于工作区路径内部，因此信任关卡仍必须将其视为不受信，直到路径获得批准。

钩子位于.claude/settings.json内部，而非独立文件；4月的公告描述了攻击者直接填充该键。¹⁶4月的漏洞还揭示了一个根本不在Claude Code配置参考之列的配置面：一个名为commondir的git内部文件，用于将工作树解析回其父仓库。⁸恶意仓库通过附带精心构造的commondir布局，使Claude Code在信任评估期间跟随该指针，从而继承目标路径的信任。这个git内部配置面打破了项目配置面的总数计算，这才是真正的教训。分类法并未封闭。攻击面由对话框触发之前哪些字节被读取所定义，任何能影响路径解析或配置的因素都属于其内。

这种模式正是MCP服务器是新的攻击面在另一个高度上所揭示的。⁹在生态系统跟上其影响之前，MCP服务器已经引爆了工具提供方的攻击面。信任对话框绕过是同一形态在低一层的体现。每一项允许仓库预配置代理的便利特性，都在上述分类法中新增一行。每一行都是本类下一个CVE的候选。

柜子背面：是加载顺序不变量，而非更聪明的对话框

Paul Jobs教导Steve说，柜子背面值得与正面同样精良的对待。¹⁰柜子比喻在这里并非装饰，而是修复方案的脊梁。

信任对话框就是柜子的背面。用户看不见加载顺序。他们看到的是对话框，点击信任，便假定工作区内的每一个字节在那次点击之前都是惰性的。实现必须配得上这一假定。当它配不上时，这一假定就成了攻击面。

加载顺序就是决定该假定是否配得上的不变量。两份公告及Claude Code公开设置文档所暗示的最小模型大致如下：²¹⁶

1. 从~/.claude/settings.json读取用户设置。
2. 从~/.claude/settings.local.json读取用户设置。
3. 评估当前工作区路径是否受信。
4. 若不受信，弹出对话框。若用户点击信任，则持久化路径。
5. 读取仓库内项目范围的.claude/settings.json。
6. 读取项目范围的.claude/settings.local.json。
7. 从合并后的设置中解析钩子、MCP服务器、技能与子代理。
8. 运行SessionStart钩子。

公告并未精确记录每一步，技能、子代理、MCP相对于设置合并的位置属于用户不可见的实现细节。但公告确实确立了第3步这个边界。在第3步之前解析的一切，处于受信输入区。在第3步及之后解析的一切，绝不可读取工作区字节。3月的漏洞调换了第3步与第5步：项目设置先被解析，这些设置所配置的权限模式（bypassPermissions）轻易满足了第3步的信任检查。²4月的漏洞将攻击移入第3步本身：工作区路径解析读取了仓库控制的commondir文件，伪造导致信任检查在攻击者选定的受信路径上完成解析。¹无论哪种情况，到了第7步或第8步时，工作区已被信任，每一个项目级配置面都基于这一票加载。

柜子背面所要求的规则只有一句：在用户显式信任工作区路径之前，不解释工作区内的任何字节。不读.claude/settings.json。不读commondir。不读CLAUDE.md。不读文件名清单。不读钩子文件。不读MCP服务器配置。只要文件在工作区内，决定信任的代码就不看它。

Visual Studio Code于2021年5月以工作区信任（1.57版本）的形式交付了这一修复。自该特性发布以来，核心文件夹信任类未再公开过绕过漏洞，尽管围绕受信域名与扩展行为的相关问题仍时有出现。¹¹¹²2.1.53版本（3月公告所引用的修复）通过调换第3步与第5步，落实了Claude Code版的不变量。²2.1.84版本（4月公告所引用的修复）通过拒绝在信任评估期间跟随仓库控制的commondir文件，落实了同一不变量。¹两者都是恢复不变量的补丁，而非发明新的防御机制。

Steve测试拉出了下一根线头：Blake愿意在这上面签名吗？¹³在这六周窗口内，对Claude Code的回答是不愿意，因为厂商两次签发、交付并修补了本类绕过漏洞。这是厂商需要解决的标准。最低值得品正是签名所参照的标准。¹⁴最低是范围约束，而非质量打折。一个最低可行的信任对话框，是能阻挡廉价攻击的对话框。一个最低值得的信任对话框，是一条加载顺序的第一步——这条加载顺序拒绝在用户作出决定前解释任何仓库字节。你交付的产品，就是你拒绝在被允许之前解释的那些字节。

不变量所要求的三项修复

规则就是不变量。三种模式直接由它推出。

单向关卡。做出信任的代码只读取路径、用户的点击，以及工作区之外~/.claude.json中持久化的信任状态。¹⁵别的什么都不读。任何让工作区文件参与信任决策的重构都是回归。

路径解析不传递信任。优选的不变量是：工作树、子模块、include文件与符号链接目标各自获得独立的提示。Visual Studio Code的工作区信任则相反，允许父文件夹信任覆盖子文件夹，而当路径解析被伪造时，正是这一选择被~/Projects这类宽泛的父路径信任所利用。更严格的规则代价是几次额外的对话框，但消除了整个传递信任的攻击面；更宽松的规则保持低摩擦，并接受路径解析漏洞会变成信任解析漏洞。¹¹

信任读取顺序回归测试中的对抗性夹具。一个刻意构造的对抗性仓库，在其中提交金丝雀工作区文件。测试断言在对话框确认之前，没有任何代码路径会读取这些金丝雀。如果运行时的未来变更在信任评估期间读取了任何金丝雀文件，构建就失败。CWE-501，Trust Boundary Violation，是值得在测试分类法中跟踪的更宽泛家族，可与已发布公告所采用的更具体的CWE-807以及CWE-20/CWE-77分类并列。¹⁶

三者均不昂贵。第一项是代码的缺席。第二项的代价是用户可见的摩擦。第三项是一次工程实施加上此后的纪律。信任引导被攻陷是一个类别，惯常的纵深防御姿态在此并不适用，因为信任下游的每一层都基于工作区刚刚帮助作出的信任决策运行。在脚手架层无法构建信任之外的防御，因为脚手架恰恰就是信任解析后工作区被允许读取的内容。

厂商必须交付这一不变量。信任对话框绕过CVE是观察者衡量厂商是否达标的方式。六周内两个不是噪声。这是一个信号：该不变量尚未在测试套件中编码为构建强制执行的断言。在它被编码之前，本类的下一个CVE只是找到第十个输入的时间问题。

仓库不应为自己的信任投票。信任是被评估工件绝不可参与作出的唯一决策。代理防御的所有其他层（钩子、技能、校验器、检测器、防护）都位于这一票之下游。当投票被操纵时，下游的工作就只是摆设。柜子的正面工艺挽救不了背面。

FAQ

什么是Claude Code信任对话框绕过？

Claude Code信任对话框绕过发生在用户尚未显式批准之前，不受信工作区被当作受信处理时。在2026年3月的CVE中，仓库控制的设置在信任被评估之前影响了权限模式。在2026年4月的CVE中，精心构造的git工作树/commondir布局导致信任通过已受信路径完成解析。

我应如何缩窄~/.claude.json中的受信路径？

打开~/.claude.json并检查projects映射。查找以下条目中hasTrustDialogAccepted为true的项：已不再持有活跃代码的目录、~/Projects这类宽泛的父路径，以及与工作树相邻布局存在重叠的任何路径。按仓库授信会增加对话框次数，但能避免一个被接受的父路径默默覆盖每一个子路径。

为何对Claude Code而言父路径信任很危险？

父路径信任之所以危险，是因为一个被接受的目录可以覆盖许多子工作区。如果路径解析被伪造，或恶意工作树指回该父路径，子仓库就会继承从未授予它的信任。按仓库授信增加摩擦，但能避免无关仓库之间的传递信任。

哪条不变量能防止信任对话框绕过？

不变量是：在用户显式信任工作区路径之前，不解释工作区内的任何字节。信任代码可以读取路径、用户的点击，以及仓库之外持久化的信任状态。它不应在对话框出现之前读取.claude/settings.json、CLAUDE.md、.mcp.json、钩子、技能、commondir，或任何仓库控制的文件。

参考文献