签名是真的分支却不对GitHub CLI 制品证明的大小写边界一、背景与时间线官方确认gh attestation verify对--source-ref使用不区分大小写的比较而 Git ref 区分大小写。攻击前提是对已信任仓库拥有写权限能够创建大小写不同的分支。证明签名与证书本身没有损坏--source-digest不受该问题影响可用于固定批准的提交。公告未列出 CVE本文只使用 GHSA 标识。以上事实依据项目安全公告。这里的披露或数据库收录日期不是攻击发生时间。本次核验的一手来源没有确认在野利用本文不据此断言不存在攻击。二、影响范围与版本边界项目核验结果公告标识GHSA-4mq3-hpgx-9cx8项目公告日期2026-09-30受影响版本2.68.0 且 2.101.0修复版本2.102.0事件性质漏洞披露或近期数据库收录非已确认攻击事件版本信息应结合实际运行环境判断。依赖清单命中仅是第一步还需要确认调用路径、配置和不可信输入能否到达相应逻辑。发行商回补补丁的情况应核对其安全公告和构建证据不能只按上游版本字符串做最终判断。三、技术原理与工程分析设发布政策允许 refs/heads/Release实际构建来自 refs/heads/release。将二者统一转为小写后原本不同的身份进入同一个等价类。问题不是字符串不够规范而是规范化规则不符合对象本身的身份规则。工程分析门禁至少存在四个不同问题——字节是否对应制品、证明是谁签发、构建来自哪个源码对象、该源码对象是否被允许发布。任何一层通过都不能代替下一层。尤其不能将仓库可信扩大为仓库中所有分支可信。建议将证明中的仓库、ref、commit 和构建工作流保留为独立字段。ref 比较遵循精确语义commit 用于固定一次批准对象策略变更单独审计。这样回溯时可以回答批准的是哪个提交而不只是哪个分支名称。四、防御性安全示例以下Python 3示例只演示安全不变量不连接网络、不执行外部程序、不生成真实利用载荷也不是厂商补丁的逐行复现。运行后应输出检查通过。expectedrefs/heads/Releaseactualrefs/heads/releaseassertexpected.casefold()actual.casefold()assertexpected!actualdefapprove(ref,digest,policy):returnrefpolicy[ref]anddigestpolicy[digest]policy{ref:expected,digest:demo-commit-A}assertapprove(expected,demo-commit-A,policy)assertnotapprove(actual,demo-commit-A,policy)assertnotapprove(expected,demo-commit-B,policy)print(policy checks passed)模型测试通过只证明这些固定输入满足预期不能证明生产部署已经修复。实际回归还需要在目标版本、真实适配层或调用封装中重复验证同一不变量。测试用例应同时覆盖正常输入和拒绝路径否则“全部拒绝”的错误实现也可能被误当成安全修复。五、研发与安全团队行动清单P0检查发布容器、Runner 镜像和开发机中的 gh 版本升级到修复版盘点使用 --source-ref 的脚本。无法立即升级时按官方建议增加 --source-digest并由可信审批流程提供提交值。P1检查目标仓库是否存在仅大小写不同的意外分支对历史部署比对证书中的原始 ref 和已批准 commit。发现不一致先保留证明、策略、执行日志再决定是否回滚不把差异直接判为入侵。P2门禁测试加入大小写变体、正确分支错误提交、正确提交错误仓库、证明缺失等负向样例。将验证器版本纳入部署证据避免构建镜像仍携带旧工具。如何形成可复核的修复证据研发负责提交调用点、配置差异和回归结果平台团队负责证明新构建已部署到实际实例安全团队复核前提是否消除并保留未覆盖环境的清单。完成条件应落在运行中的版本与行为而非工单状态或补丁合并时间。建议对每个服务记录组件实际版本、受影响功能是否启用、输入来源、修复负责人、部署批次及失败回滚方案。无需搜集完整敏感输入用脱敏样本和配置摘要通常更适合审计。对于无法及时升级的实例临时措施必须指定复核日期避免长期漂移为默认设计。六、总结这项问题提醒我们安全约束必须与最终执行语义一致。识别依赖版本、定位真实调用链、验证负向行为、确认部署完成缺少任何一步都可能让修复停留在纸面。本文的工程建议用于补充系统设计不应被误读为厂商已确认的额外攻击链。