🏷️ GitHub, CVE-2026-3854, RCE, X-Stat, Wiz, git push, 跨租户, IDA MCP, AI安全

一条git push命令，攻陷数百万代码库

2026年4月，一个普通的星期二

2026年4月2日，星期二。Wiz Research的安全研究员Elad Gabai像往常一样，打开了IDA Pro，开始分析GitHub的内部git基础设施。

他不是在找漏洞。他只是在做一个常规的安全研究项目——研究大型平台的多服务架构如何处理用户输入。

三天后，他发现了一个漏洞。

又过了两天，他确认了这个漏洞可以被利用。

再然后，他发现这个漏洞不仅仅影响GitHub Enterprise Server（企业版），还能影响GitHub.com——全球最大的代码托管平台，数亿个代码仓库的主场。

整个过程，从发现到完整利用，花了不到一周。但这个漏洞已经在GitHub的代码库中潜伏了多久，没有人知道。

这个漏洞的编号是CVE-2026-3854。它的发现，可能会改变安全研究的未来——因为研究员使用AI工具辅助完成了这次发现。

而它的攻击方式，简单到令人发指：只需要一条git push命令。

一个git push命令的背后

当你执行git push时，发生了什么？

远没有你想的那么简单。一个git push请求，在GitHub的内部要经过至少四个关键服务：

babeld——git代理，所有的git操作的入口。它接收用户的SSH连接，然后转发给gitauth进行认证。

gitauth——内部认证服务。它验证用户的凭证，检查用户是否有推送权限，然后返回适用于该会话的安全策略——文件大小限制、分支命名规则等。babeld拿到这个响应后，构造一个内部标头，包含所有这些安全元数据。

gitrpcd——内部RPC服务器。它从babeld接收请求，解析那个内部标头，为下游进程设置环境。关键的是，gitrpcd不做自己的认证——它完全信任babeld，把标头中的每个字段都当作权威的。

pre-receive hook——一个编译后的Go二进制文件，在推送被接受之前运行。它检查文件大小限制、分支命名规则、LFS完整性，以及任何管理员定义的自定义钩子。

连接这些组件的关键，是那个被称为X-Stat的内部标头。它携带安全关键字段，以分号分隔的key=value对的形式存在。内部服务通过按分号分割来解析这个标头，然后填充到一个map中。

一个关键细节：map使用”最后写入生效”语义。如果一个key出现两次，后面的值会静默覆盖前面的。

当用户运行带选项的git push时，git push -o some-option，这些选项被babeld编码为编号字段——push_option_0、push_option_1，等等——然后加上一个push_option_count。

这本身没有问题。问题在于：babeld直接把用户提供的选项值复制到X-Stat标头中——没有过滤分号。

分号的魔法

由于分号是X-Stat字段的分隔符，任何push选项值中的分号都会破坏它的指定字段，创建新的、攻击者控制的字段。

考虑一个包含分号的push选项值，后跟一个安全字段名。babeld原样嵌入它，产生这样的标头：

push_option_0=value;rails_env=production

按分号分割后，解析为： - push_option_0 = “value” - rails_env = “production”

攻击者的值获胜，因为它出现在标头的后面——最后写入生效。

现在，攻击者可以覆盖这些关键字段： - rails_env - 控制hook执行路径（沙箱 vs 直接执行） - custom_hooks_dir - 自定义hook脚本的基础目录 - repo_pre_receive_hooks - 要执行的pre-receive hook定义

这三个字段串联起来，就是完整的RCE。

完整的攻击链

第一步：绕过沙箱。注入一个非生产的rails_env值，将执行路径从沙箱的生产路径切换到无沙箱的路径。

第二步：重定向hook目录。注入custom_hooks_dir来控制hook脚本查找的基础目录。

第三步：注入hook定义。注入repo_pre_receive_hooks，其中包含路径遍历序列的hook条目。hook二进制的路径解析将攻击者控制的基础目录与遍历有效载荷连接起来，解析为文件系统上的任意二进制。

然后，非生产路径直接执行解析后的路径——无参数，无沙箱——以git服务用户身份。

有了无沙箱的代码执行，攻击者完全控制了GHES实例，包括文件系统读写访问和内部服务配置的可见性。

从GHES到GitHub.com

研究员们在GHES上实现了RCE。下一个问题是：GitHub.com上也能工作吗？

他们在GitHub.com上运行了同样的利用链。推送成功完成，但自定义hook从未执行。没有远程输出，没有代码执行——什么也没有。

他们注入了user_operator_mode=bool:true来启用debug输出，在两个平台上比较输出。他们注意到GitHub.com上缺少某些在GHES上出现的hook执行步骤——自定义hook代码路径根本没有被达到。

他们在二进制中挖得更深。通过进一步逆向工程，他们识别出X-Stat标头中的一个布尔标志，控制服务器是否在企业模式下运行。在GHES上，这个标志默认为true——所以自定义hook路径始终处于活跃状态。在GitHub.com上，它默认为false，意味着在正常条件下自定义hook永远不会被到达。

由于这个标志也是通过X-Stat标头携带的，它可以通过相同的机制被注入。再注入一个字段，完整的利用链在GitHub.com上生效了。

这次，他们执行了hostname而不是id:

Remote: remote: Running hook: hostname

GitHub.com上的RCE——确认。

跨租户的灾难

在GitHub Enterprise Server上，RCE已经是一个严重漏洞。在GitHub.com上，同样的缺陷有更广泛的含义。

GitHub.com是一个多租户平台。数百万不同组织和用户的仓库存储在共享的后端基础设施上。当他们在GitHub.com上实现代码执行时，他们降落在运行git用户的共享存储节点上。

git用户的存在是有原因的：它为节点上的所有仓库操作服务。设计时，它对该节点上托管的每个仓库都有广泛的文件系统访问权。攻破这个用户意味着他们可以读取该节点上的任何仓库，无论哪个组织或用户拥有它。

他们在两个被攻破的节点上枚举了仓库索引条目，发现了数百万条——属于其他用户和组织。

他们没有访问其他租户仓库的内容。 他们使用自己的测试账户验证了跨租户暴露，确认git用户的文件系统权限允许读取该节点上的任何仓库。

这是一个可怕的事实：一个普通的GitHub用户，只需要一条git push，就能读取数百万其他用户的私有代码。

AI发现的高危漏洞

Wiz的研究人员是如何发现这个漏洞的？答案可能让未来的安全研究者既兴奋又担忧：

他们使用了AI。

具体来说，他们使用了IDA MCP——一个AI增强的逆向工程工具，可以自动化分析闭源二进制文件。

这是安全界首次使用AI在闭源安装文件���发��如此严重的基础底层漏洞。这证明了AI技术正在重塑复杂的安全研究工作流。

传统的逆向工程需要数周的不懈努力——提取和审计运行这个管道的compiled blackbox二进制文件的 volumes。但使用AI，他们能够：

  • 快速分析GitHub的compiled二进制
  • 重建内部协议
  • 系统地识别用户输入可以在整个管道中影响服务器行为的位置

Wiz在博客中写道：”由于这种新能力，我们发现了GitHub多服务架构中处理输入的一个根本性缺陷。”

这是一个里程碑：AI不仅可以帮助写代码，还可以帮助发现漏洞。 随着这些工具继续成熟，我们期望它们在发现需要深度跨组件分析的漏洞类别方面发挥越来越重要的作用。

GitHub的响应

2026年3月4日——Wiz发现漏洞并确认在GHES上的RCE。

同一天——Wiz向GitHub报告了该漏洞。

2026年3月4日之后的六小时内——GitHub修复了GitHub.com上的云平台，并发布了GHES补丁。

截至2026年4月29日撰写本文时，88%的GHES实例仍然运行在易受攻击的版本上。

GitHub已发布所有支持版本的补丁： - GHES 3.19.3 及更高版本 - GHES 3.18.6 及更高版本 - GHES 3.17.12 及更高版本 - GHES 3.16.15 及更高版本 - GHES 3.15.19 及更高版本 - GHES 3.14.24 及更高版本

管理员必须立即更新。

多服务架构的警示

CVE-2026-3854不仅仅是一个GitHub漏洞。它展示了跨多服务架构的一个模式：

当多个用不同语言编写的服务通过共享内部协议传递数据时，每个服务对数据的假设成为一个关键的攻击面。

在这个案例中： - 一个服务假设push选项值可以安全地原样嵌入 - 另一个服务假设X-Stat标头中的每个字段都是由可信源设置的 - pre-receive hook假设环境变量在生产环境中只能是production

每个单独的假设都是合理的——组合起来是危险的。

生产二进制中的非生产代码路径、hook脚本缺乏路径遍历验证、使用基于分隔符的协议而没有输入清理——这些模式在许多代码库中都出现过。

对于构建多服务架构的团队，Wiz的建议是：审计用户控制的数据如何通过内部协议流动——特别是在安全关键配置来自共享数据格式的地方。

给管理员的行动建议

对于GitHub Enterprise Server管理员：

  1. 立即升级到GHES 3.19.3或更高版本——这是唯一已修复该漏洞的版本
  2. 审计日志中是否有异常的git push行为——特别是带有自定义push选项的推送
  3. 限制对git用户可访问的文件系统的访问——即使是管理员也要遵循最小权限原则
  4. 考虑禁用自定义hook——如果不需要这个功能

对于GitHub.com用户：

  • 目前无需采取行动——GitHub.com已修复
  • 但如果你使用GHES——请立即更新

对于整个行业：

  • 多服务架构是现代云的常态，但每个服务之间的数据流是隐藏的攻击面
  • AI辅助的漏洞发现正在变得可行——这既是威胁也是机会
  • “最后写入生效”的假设在安全关键配置中可能是致命的

信息来源

返回博客列表