Claude Code 用户近期发现了一个令人生疑的计费路由漏洞：当 Git 提交历史中出现特定字符串时，系统会绕过订阅配额，转而扣除额外的 API 调用费用。2026 年 4 月，多位用户在 Reddit 和技术社区报告了这一问题，其中一位用户因该漏洞在数小时内损失超过 200 美元。本文从输入验证的工程视角切入，分析这一异常的技术根因，并探讨外部输入对内部路由逻辑的影响机制。
触发条件的具体表现
问题的核心在于一个看似无害的字符串：大写的 HERMES.md。根据多位用户的独立验证，以下条件组合构成完整触发链：首先，提交信息中必须包含完整的大写字符串「HERMES.md」，注意这里是三个字母全大写且包含 .md 扩展名；其次，该提交需要出现在最近的可枚举提交历史中，因为 Claude Code 会将近期提交内容纳入系统提示词；最后，用户需要处于 Max 订阅计划而非纯 API 付费模式。满足上述条件后，原本应走计划配额的消息请求会被静默路由至额外使用量计费通道，用户在不知不觉中被扣除 API 费用。值得注意的几点细节是：小写的「hermes.md」不会触发、大写的「HERMES」不带 .md 扩展名也不会触发、「AGENTS.md」等其他类似格式同样安全。这表明问题并非简单的字符串包含检测，而是一个针对特定模式的硬编码路由分支。
技术层面的根因分析
从架构角度看，Claude Code 在执行任务时会读取工作区的 Git 元数据，其中最近的几条提交消息会被提取并拼接到发送给语言模型的系统提示词中。这一设计的初衷是为模型提供项目变更的上下文信息。然而，问题出现在后端的路由层：当请求到达计费系统时，系统似乎在解析请求上下文时对特定的字符串模式进行了匹配，并将匹配结果作为路由决策的依据。这里的关键在于，提交消息本应仅作为语义上下文使用，不应影响计费路由逻辑；但在实际实现中，这些外部输入被不当暴露给了计费决策模块。安全设计的基本原则之一是「不可信输入验证」，即所有来自用户侧的数据在进入核心业务逻辑前都必须经过严格的校验和隔离。提交消息作为一种完全由用户控制的自由文本，天然属于不可信输入的范畴。当这类输入未经清洗就直接影响计费路由时，就产生了输入验证缺失导致的业务逻辑劫持风险。
进一步推断可能的实现方式：开发团队可能在某个早期版本中为特定的营销活动或内部测试添加了临时的路由规则，该规则以字符串匹配的方式识别特定场景（如检测到 HERMES.md 时认为该请求来自特定的外部集成），并将这部分流量导向不同的计费渠道。问题在于，这段临时逻辑在后续迭代中未被移除，或者被遗忘在了生产代码中，最终形成了静默的路由漏洞。由于触发条件依赖于大小写敏感的精确字符串匹配，这种问题在常规测试中很难被发现，因为测试用例通常不会刻意构造如此特殊的提交消息。
工程实践中的防护机制
这一案例揭示了几个值得关注的工程实践问题。第一是输入隔离原则的缺失，Claude Code 将提交历史纳入提示词上下文的做法本身是合理的，但这些外部输入不应该渗透到计费、权限等关键决策路径上。更稳妥的做法是只将提交内容的语义摘要（如变更文件列表、提交时间）提供给模型，而将元数据与业务逻辑完全解耦。第二是路由逻辑的硬编码匹配风险，在代码中直接使用字符串比较来区分不同的业务场景是一种反模式，当匹配的目标字符串恰好与用户的正常输入冲突时就会触发意外行为。对于需要识别特定场景的场景，应该使用内部标识符而非用户可控的文本内容。第三是计费异常的监控不足，用户报告指出从触发到扣费的过程中没有任何警告或确认提示，这说明系统缺乏对异常计费模式的实时检测能力。作为改进，系统可以设置单次会话的计费阈值告警，当检测到用户即将超出其计划配额时主动提示，而非等到余额耗尽才报错。
针对使用 Claude Code 的开发者，以下是具体的自检清单：立即检查项目中最近的提交历史是否包含 HERMES.md 字符串，特别是大写形式；定期在账户设置中核对使用量明细，区分计划配额与额外扣费；如果发现异常扣费，建议保留完整的复现步骤和日志截图以便向技术支持申诉；从长期看，尽量避免在提交信息中使用过于通用或与知名项目同名的文件名模式，即使这种风险在技术上极为罕见。
小结
HERMES.md 漏洞的本质是外部输入验证缺失导致的计费路由异常。提交消息作为完全由用户控制的输入，在未被适当隔离的情况下影响了核心业务逻辑。这一案例提醒我们，在构建 AI 辅助开发工具时，任何来自用户环境的元数据都应被视为潜在的攻击面或异常来源，输入验证与逻辑隔离是防止类似问题复发的关键工程实践。
资料来源：本文技术细节主要基于 Reddit 用户在 r/ClaudeAI 社区的原始报告，该报告详细描述了问题发现过程、复现步骤及 Anthropic 官方支持的回应；daily.dev 等技术聚合平台也对此事进行了跟踪报道。