你可能正在用GitHub存你最重要的代码。
全球最大的代码托管平台，1亿+个仓库，无数企业的命脉。
结果被几个安全研究员发现——只要一个git push命令，就能远程执行任意代码，黑进GitHub的后台。
是的，你没看错。
你每天用的那个git push origin master，在特定条件下，可以变成一把钥匙。
打开的，是整个GitHub的防线。
事情是怎么发现的？
发现这个漏洞的，是Wiz Research团队。
他们专门干一件事：找云厂商和代码平台的安全漏洞。
这一次，他们把目光盯上了GitHub的内部git基础设施。
这玩意儿很复杂。当你在本地执行git push，你的请求会经过好几个内部服务：babeld（入口）、gitauth（认证）、gitrpcd（RPC服务器）、还有一个预接收钩子（pre-receive hook）。
每个服务写的语言不一样，传递数据的方式也不一样。
问题就出在这儿。
Wiz团队用了一个新方法：AI辅助逆向工程。
他们用IDA MCP这个工具，快速分析了GitHub那些闭源的二进制文件，重构了内部协议，找到了用户输入可能影响服务器行为的地方。
这是首批用AI在闭源二进制文件中发现的关键漏洞之一。
效率高得吓人。
以前需要几个人干几周的事，现在AI几天就搞定了。
一个分号引发的血案
漏洞的核心，是一个叫X-Stat的内部header。
简单说，当你的git push带着push option（推送选项）到达服务器时，babeld服务会把你的选项直接塞进X-Stat header里。
但它没有过滤分号。
而X-Stat是用分号做分隔符的。
这意味着什么？
意味着攻击者可以在push option里插入一个分号，后面跟一个伪造的字段名。
服务器解析的时候，后面的值会覆盖原来的字段。
这就是经典的注入攻击。
Wiz团队顺藤摸瓜，发现可以通过注入三个字段实现完整的攻击链：
- rails_env — 覆盖环境变量，把代码执行从沙盒模式切换到直接执行模式
- custom_hooks_dir — 控制钩子脚本的查找目录
- repo_pre_receive_hooks — 注入一个带路径穿越的钩子定义
三枪开火，直接RCE。
在GitHub Enterprise Server上，他们成功执行了id命令，获得了git用户的权限。
然后他们把同样的攻击链搬到GitHub.com。
第一次，没成功。
他们又回头分析，发现GitHub.com默认不启用企业模式，而这个标志位也在X-Stat header里。
再补一枪，RCE on GitHub.com。
一个git push，远程代码执行，确认。
最恐怖的还在后头
GitHub.com是多租户架构。
什么意思？
不同的公司、不同的组织，共用同一套后端基础设施。
当Wiz获得git用户的权限后，他们发现这个用户可以访问存储节点上的所有仓库。
他们只做了验证：枚举了两个被攻破的节点上的仓库索引。
每个节点上有数百万个条目，属于不同的用户和组织。
理论上，攻击者可以读取任何仓库的内容——只要它和攻击者在同一个节点上。
Wiz说他们没有真的去读，只是验证了权限模型允许这么做。
但这个验证本身，已经足够让人后背发凉。
GitHub的回应：快，但不够快
从报告到修复，GitHub的速度其实很快。
3月4日，Wiz发现漏洞并报告。
同一天，GitHub确认收到。
6小时后，GitHub.com的漏洞被堵住。
3月10日，CVE分配，GHES补丁发布。
4月28日，公开披露。
速度没得说。
但有一个数据很尴尬：
截至这篇博客发布时，88%的GitHub Enterprise Server实例仍然存在漏洞。
7周过去了。
88%。
这个数字让我想起了Windows系统的补丁安装率。
企业级软件，升级有时候比登天还难。
生产环境不能随便动，兼容性要测，IT审批要走流程。
但这个漏洞的严重程度是CVSS 8.7，高危。
一个认证用户，一条命令，直接RCE。
那些没升级的企业，等于裸奔。
这事儿给我们什么启示？
Wiz团队在博客里写了一段话，我觉得很值得细看：
当多个用不同语言写的服务，通过一个共享的内部协议传递数据时，每个服务对数据的假设，就成了攻击面。
一个服务假设push option的值是安全的，可以直接嵌入。
另一个服务假设X-Stat header里的每个字段都是可信来源设置的。
预接收钩子假设rails_env只能是production。
每个假设单独看都挺合理，放在一起，就是灾难。
用户输入永远不应该被信任。
不管它来自哪里，不管它经过多少层服务。
该过滤的过滤，该校验的校验，该隔离的隔离。
这道理说了多少年了，还是有人在前仆后继地踩坑。
另外，AI在安全研究里的角色，越来越重要了。
Wiz自己说，用AI辅助逆向工程，让以前"不切实际"的工作变得可行。
AI不会累，不会烦，能快速处理大量二进制代码，找出人类容易漏掉的模式。
这对安全研究员是好事。
但对攻击者呢？
攻防两端都在进化。
就看谁跑得更快。
最后说几句
这个漏洞现在应该已经修得差不多了。
GitHub.com没问题，GHES的补丁也早就出来了。
但88%这个数字，提醒我们一件事：
安全不是下载一个补丁就完事了。
它是一个持续的、痛苦的、没人爱干但必须干的过程。
而GitHub，作为全球最大的代码托管平台，掌握着无数企业的命脉，它出的任何问题，影响都会被放大。
有评论说："GitHub的案例会成为商学院教材里的经典案例，讲述一家公司如何差点毁掉自己的垄断地位。"
有点夸张，但也不是没道理。
毕竟，不是每个平台都有机会从一个git push里活下来。
【锐评】：
88%的GHES实例7周不升级这件事，比漏洞本身更说明问题——企业安全很多时候不是技术问题，是执行力问题。而AI发现闭源漏洞这个趋势，才是真的要变天了。
参考链接：
https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854