漏洞详情

该漏洞源于 GitHub 内部协议 X-Stat 头部中的注入缺陷。当用户通过 SSH 向 GitHub 推送代码时，请求会经过多个内部服务组件：babeld（git 代理入口）、gitauth（认证服务）、gitrpcd（内部 RPC 服务器）以及 pre-receive 钩子（安全检查）。

这些组件之间通过 X-Stat 头部传递安全元数据，该头部使用分号分隔的键值对格式。关键问题在于，babeld 在将用户的 git push 选项值复制到 X-Stat 头部时，未对分号进行转义处理。攻击者可以在 push 选项中注入包含分号的恶意值，从而创建新的、受攻击者控制的字段。

由于 X-Stat 头部采用"最后写入优先"的语义，攻击者注入的字段会静默覆盖合法的安全字段。研究团队映射出多个可注入的安全关键字段，包括 rails_env（控制钩子执行路径）、custom_hooks_dir（钩子脚本目录）和 repo_pre_receive_hooks（预接收钩子定义）。

利用链条

漏洞的利用链条由三个注入步骤组成：

1. 绕过沙箱：注入非 production 的 rails_env 值，将执行路径从沙箱环境切换到无隔离的直接执行模式
2. 重定向钩子目录：注入 custom_hooks_dir 控制钩子脚本的查找基目录
3. 注入钩子定义：通过路径遍历注入精心构造的钩子条目，最终在文件系统上执行任意二进制文件

在 GitHub Enterprise Server（GHES）上，完整的利用链可以获得对实例的完全控制权，包括所有托管仓库和内部机密。在 GitHub.com 上，漏洞允许在共享存储节点上执行远程代码，研究团队确认数百万公共和私有仓库在受影响的节点上可被访问。

AI 辅助发现

值得注意的是，这是首批使用 AI 技术在闭源二进制文件中发现的关键漏洞之一。Wiz 团队利用 AI 增强的工具——特别是使用 IDA MCP 进行自动逆向工程——快速分析了 GitHub 的编译二进制文件，重建了内部协议，并系统地识别了用户输入可能影响服务器行为的各个环节。

修复状态

GitHub 在收到报告后 6 小时内对 GitHub.com 进行了缓解修复，并为所有受支持的 GHES 版本发布了补丁。然而，截至报告发布时，数据显示 88% 的 GHES 实例仍然存在漏洞。GitHub 企业服务器客户被建议立即升级到 3.19.3 或更高版本。

GitHub CISO Alexis Wales 表示：“这一级别的发现的严重性是罕见的，在我们的漏洞赏金计划中获得了最高奖励之一。”

Source: Wiz Blog