GitHub “已验证”提交可被改写为新哈希且不破坏签名
导语：卡内基梅隆大学博士生 Jacob Ginesin 的研究表明,GitHub 的"已验证"提交机制存在签名可锻性问题——攻击者无需签名密钥即可生成哈希不同但签名同样有效的"孪生"提交,绕过基于哈希的封禁与去重机制。修复责任在代码托管平台侧。
核心发现
新研究显示,一份已签名 Git 提交的哈希,并非整个软件行业所假定的那种独一无二的名称。给定任意一个已签名的提交,即使没有签名密钥,攻击者也可以铸造出第二个提交——文件、作者、日期完全相同,签名仍然有效,而 GitHub 仍会盖上"Verified(已验证)"的戳。审阅者会检查的一切内容都吻合,唯有提交的哈希对不上。这事关重大,因为有太多系统把已验证的提交哈希视为其内容的永久唯一标识。
具体失效场景
具体的失败方式如下:用哈希来封禁一个恶意提交,攻击者就可以在封禁名单从未见过的新哈希下,以同样"Verified"的状态重新推送相同内容。以哈希为键进行的去重、来源日志以及可复现构建记录,都会继承同样的软肋。一个被入侵或恶意的镜像源,也可以向克隆者交付哈希与官方代码托管平台不同、但仍带有有效签名的提交。
关键澄清
需要说明的是,这并不是一种让不同代码通过签名检查的方法。每个副本中的文件完全一致,因此你钉死的哈希仍然能取回你预期的内容,要么成功,要么失败。此问题没有 CVE,也没有厂商公告,你自己仓库里也无需做任何更改:缺陷出在代码托管平台如何定义"Verified"上,修复也应由平台侧完成。
研究来源与作者
这项研究来自 Jacob Ginesin,卡内基梅隆大学的博士生,同时也是 Cure53 的密码学审计员。他的五页论文于 7 月 2 日发布在 arXiv 上,论文附带一个可执行全部三种攻击的公开工具,以及两个示例仓库,其中的可锻化提交在 GitHub 上仍然显示"Verified"。
哈希链可锻性的成因
由于每个提交都通过哈希来指明其父提交,锻化一个提交会强制其上游所有提交生成新哈希。该工具会重写整条链以保持一致性。然而,一旦父提交指针发生变化,已签名的后代提交就会失去自己的"Verified"徽章。Ginesin 将这种效应称为"哈希链可锻性(hash chain malleability)"。其根本原因是签名可锻性:提交的哈希是基于其内部所有内容计算得出,包括头部中签名的原始字节。许多签名可以被改写成另一种不同但仍然有效的形式,这些字节的改变会改变哈希,但不会改动任何一行代码。
攻击面与 GitHub 的处理
论文给出的三条攻击路径覆盖了 GitHub 所验证的每一种 GPG 方案,以及 S/MIME。这三条路径都有一个共同前提:GitHub 在校验签名之前并不对其进行规范化——S/MIME 没有严格的编码约束,OpenPGP 相关字段没有被剥离,非规范的 ECDSA 值被原样接受。GitHub 随后针对每个提交哈希生成一条"Verified"记录,并且不会重新校验。因此,即使签名密钥被吊销,该提交仍保持"Verified"状态。将原提交与其孪生提交推送到两个分支,GitHub 的比较视图会将它们视为两条分叉的历史——一个领先一个落后,尽管文件完全相同。
并非哈希碰撞
需要明确指出:这并不是哈希碰撞。它既不破坏 SHA-1,也不破坏 SHA-256,与 Git 向 SHA-256 的迁移毫无关系。没有人能让两个不同的提交共享同一个哈希;情况正好相反——一个提交可以被以多种有效方式书写,每种方式各有自己的哈希。这种核心手法其实早已存在。比特币多年前就处理过完全相同的 ECDSA 对称性问题:当时任何人都可以翻转交易签名中的 s 值,在无需私钥的情况下改变交易 ID。修复方案是只接受"低 S(low-S)"形式,后来又通过 SegWit 将签名移出交易 ID 之外。论文给出的修复思路与之呼应:在信任哈希之前先对签名进行规范化处理。这是一条已知的经验,并非某种新奇密码学。
与近期供应链攻击的关联
论文还将该问题与近期发生的 GitHub Actions 标签劫持事件联系起来,包括 2025 年的 tj-actions/changed-files 事件和 2026 年的 trivy-action 攻击(论文引用了后者)。这些事件之后,业界给出的建议很简单:钉死完整的提交哈希,而不是可变动的标签。该建议至今仍然成立。钉死哈希确实阻止了那些攻击,本项研究也并未改变这一点。其论点更窄:在 Trivy 案例中,恶意提交因为无法被有效签名而格外显眼。本文是一次警示,提醒不要过度依赖这种特征——有效签名只能证明谁签了这份提交,但并不能让提交的哈希成为其内容的独一无二标识。
谁需要采取行动
那么究竟谁需要采取行动?并不是钉死某个 Action 或模块的开发者——钉死的哈希仍然能取到正确的代码。真正需要做的是代码托管平台。论文指出,平台应当在信任签名之前先对其进行规范化处理。
来源信息
来源：The Hacker News
原文链接：https://thehackernews.com/2026/07/github-verified-commits-can-be.html
作者：info@thehackernews.com (The Hacker News)
