漏洞发现与技术原理
Wiz研究团队通过对闭源编译二进制文件进行AI增强逆向工程，发现该漏洞源于GitHub内部babeldgit代理处理用户提供的推送选项值时，对特殊元素(CWE-77)的中和处理不当。当用户执行git push -o命令时，任意选项字符串会被传递至服务器。由于babeld将这些值原样复制到以分号分隔的内部X-Stat标头中，却未对作为字段分隔符的分号字符进行净化处理，从而产生漏洞。
由于下游服务gitrpcd采用"最后写入优先"的语义解析X-Stat标头，攻击者只需在推送选项中嵌入分号后跟字段名和值，即可注入新的键值字段。包括rails_env、custom_hooks_dir和repo_pre_receive_hooks在内的安全关键字段均可通过这一注入向量被覆盖。
漏洞利用链分析
实现RCE需要串联三个注入字段：
绕过沙箱——注入非生产环境的rails_env值，将预接收钩子二进制文件从沙箱执行路径切换至非沙箱直接执行路径
重定向钩子目录——覆盖custom_hooks_dir以重定向二进制文件搜索钩子脚本的位置
路径遍历实现任意执行——注入包含路径遍历有效载荷的repo_pre_receive_hooks条目，导致二进制文件解析并直接以git服务用户身份执行任意文件系统二进制文件
整个漏洞利用过程无需特权提升、特殊工具或0Day依赖——仅需标准git客户端即可完成。
影响范围与修复情况
在GitHub Enterprise Server上，成功利用该漏洞可获得服务器完全控制权，包括对所有托管代码库和内部机密的读写权限。在GitHub.com平台上，Wiz最初发现自定义钩子代码路径默认处于非活动状态，但随后发现X-Stat标头中的布尔型enterprise_mode标志同样可被注入，从而在GitHub.com共享基础设施上实现完整攻击链。
Wiz在GitHub.com共享存储节点上实现RCE后确认，git服务用户可访问这些节点上属于其他用户和组织的数百万代码库文件系统。研究人员仅使用自己的测试账户验证跨租户暴露情况，未访问第三方内容。
值得注意的是，这是首批通过大规模AI工具发现的闭源二进制文件关键漏洞之一。Wiz利用IDA MCP进行自动化逆向工程，快速重建GitHub跨编译二进制文件的内部协议，这种分析若采用人工方式将耗费难以承受的时间成本。这标志着针对不透明的多服务架构的漏洞研究方法发生了重大转变。
GitHub于2026年3月4日收到报告，数小时内完成验证，并于UTC时间同日19:00前向GitHub.com部署修复补丁，响应时间约6小时。GitHub取证调查确认漏洞披露前未被利用。
修复建议
对于GitHub Enterprise Server用户，需立即采取行动安装补丁：
|
组件 |
受影响版本 |
修复版本 |
|
GitHub Enterprise Server |
≤ 3.19.1 |
3.14.25. 3.15.20. 3.16.16. 3.17.13. 3.18.8. 3.19.4+ |
漏洞披露时Wiz数据显示88%的GHES实例仍未打补丁。GitHub Enterprise Cloud和GitHub.com用户无需采取行动。GHES管理员还应审计/var/log/github-audit.log日志，检查推送操作选项中是否包含异常特殊字符，作为先前攻击尝试的指标。
