GitHub 被分号击穿信任防线，AI 逆向工具敲响闭源系统安全警钟

GitHub 被分号击穿三层信任AI 填平逆向护城河敲响闭源系统安全警钟2026 年 3 月 4 日GitHub 收到 Wiz 通过 Bug Bounty 提交的报告报告描述的攻击入口极其简单一条构造过的 git push带一个 push option值里藏了一个分号。40 分钟内GitHub 内部复现了漏洞从确认根因到云端修复上线总计约 75 分钟不到 2 小时。任何对某个仓库拥有 push 权限的已认证用户理论上都能在处理这次 git push 的 GitHub/GHES 后端服务器上执行任意命令。虽然 GitHub 官方博客写得很清楚「没有任何客户数据被访问、修改或外泄。」GitHub 表示由于该利用链会触发正常 GitHub.com 操作不会走的异常代码路径他们据此查询遥测未发现除 Wiz 测试外的触发记录。Wiz 自己也说「我们没有访问任何其他租户的仓库内容。」但这次事件仍然撬开了那个被信了多年的内部信任假设。一个分号 击穿三层信任要看懂这次的漏洞链得先看清 GitHub 内部那条 push 流水线长什么样。你执行 git push请求进入 GitHub 内部的第一站叫 babeld它是 GitHub 自研的 git 代理负责把你的连接往下转。babeld 先去问 gitauth这个用户有没有权限这次 push 该遵守哪些规则gitauth 回来给一张清单文件大小上限、分支命名规则、hook 配置。babeld 把这张清单打包进一个叫 X-Stat 的内部请求头往下传给 gitrpcd。gitrpcd 是内部的 RPC 服务它只认这个头完全信任里面的每一个字段。最后负责最终检查的 pre-receive hook 拿到 X-Stat决定这次 push 能不能过。整条流水线X-Stat 头就是通行证。GitHub 内部 git push 流水线babeld → gitauth → gitrpcd → pre-receive hook这个 X-Stat 头是一串以分号隔开的 keyvalue比如 a1b2c3。解析的时候系统把它们依次读进一个 map。有个细节很关键如果同一个 key 出现两次后面那个会悄悄把前面那个覆盖掉。问题出在哪git push 有个正常功能叫 push option允许你在推代码时顺带传一些自定义字符串给服务端。babeld 会把这些字符串原样编进 X-Stat比如你传了两个 option它就变成 push_option_0你传的内容push_option_1你传的内容。babeld 忘了一件事没有过滤分号。X-Stat 里本来有个字段 large_blob_rejection_enabledbool:true是文件大小限制的开关默认开着。攻击者构造一个 push option值里塞一个分号后面跟上 large_blob_rejection_enabledbool:false。babeld 原样写进去X-Stat 里同一个 key 就出现了两次。map 解析到重复的 key后写入的值覆盖前面那个。攻击者注入的 false 排在后面赢了。文件大小限制就这么被关掉了。整个攻击的地基就是 babeld 少写的那一行过滤代码。这个漏洞背后的逻辑在很多系统里都存在。多个服务串在一条流水线上每一站只管干自己的活默认上一站传过来的数据是干净的、没有问题的。没有人在中间做二次检查。结果就是babeld 没拦住分号gitrpcd 收到数据不验证pre-receive 拿到字段直接用。每一站都默认上一站传来的是干净的、可信的。三层信任叠在一起一个分号全部击穿。注入三个字段 GHES 实例沦陷绕过文件大小限制只是 Wiz 用来验证注入可行的第一个测试。真正的目标是拿到服务器的执行权限。第一步把沙箱关掉。GHES 允许管理员自定义一些 hook 脚本在代码推送前自动运行。这些脚本默认在沙箱里跑权限受限。但 Wiz 逆向分析后发现沙箱是否启用取决于 X-Stat 头里一个叫 rails_env 的字段。值是 production进沙箱填任何其他值直接以 git 服务账户身份运行没有任何隔离。这个字段可以注入。第二步把 hook 脚本的查找目录换掉。注入 custom_hooks_dir把系统查找 hook 脚本的根目录从默认位置改成攻击者能控制的地方。第三步指定一个恶意脚本来执行。注入 repo_pre_receive_hooks在里面填一段路径穿越让系统跳出正常目录范围去执行服务器上任意一个二进制文件。三步串起来GHES 服务器返回了这样一行输出remote: uid500(git) gid500(git) groups500(git)。这行输出的意思是代码已经在服务器上以 git 账户身份执行了。这说明研究员已经能以 git 服务账户身份在 GHES 服务器上执行命令。Wiz 把同样的攻击链对准 GitHub.com没成功。push 走完了hook 没有触发服务器什么都没返回。继续逆向。Wiz 发现 X-Stat 里还藏着一个标志位控制服务器是否以「企业模式」运行。GHES 上这个标志默认开着自定义 hook 一直可以跑GitHub.com 上默认关着自定义 hook 根本不会被触达。但这个标志也在 X-Stat 里。也可以注入。补上这第四步整条链路打通了。Wiz 在 GitHub.com 上执行了 hostname服务器返回了一个.github.net 结尾的内部主机名。进去了。GitHub 在事后博客里坦承了一件事那条非 production 的执行路径本来就不应该出现在 GitHub.com 的生产环境里。早期部署时专门把这段代码排除掉了后来部署方式改了排除的逻辑没有跟着迁移过来这段代码就这么悄悄留在了镜像里一直没人注意到。漏洞利用之所以能贯通正是因为这段「不该在那里」的代码恰好在那里。Wiz 枚举了两台被攻陷的节点每台上都看到了百万级其他用户和组织的仓库索引项他们表示没有读取任何其他用户的仓库内容。只是用自己的测试账户确认了一件事git 用户的权限确实能访问这台节点上任何一个仓库。GitHub 的日志也印证了这一点。那条异常代码路径所有触发记录全部指向 Wiz 自己的测试流量没有其他账户出现过。能访问和真的去读了是两件性质完全不同的事。这次是前者不是后者。但根本问题还是出在多租户平台的底层设计上。GitHub.com 把大量用户和组织的仓库放在同一批服务器上统一交给同一个 git 服务账户管理因为这个账户本来就需要处理所有人的数据。任何人只要拿到这个账户的执行权限该节点上的大量仓库都会进入权限视野。共享底座带来了效率也带来了这个去不掉的结构性脆弱点。云端两小时打完补丁 本地可能要补半年真正难收尾的是自建的 GHES。Wiz 公开披露时数据显示 88%的 GHES 实例还没打补丁。按 GitHub 官方行动建议和 NVD 当前记录管理员应升级到对应受支持分支的最新补丁版NVD 当前列出的修复版本为 3.14.25、3.15.20、3.16.16、3.17.13、3.18.7、3.19.4GitHub 官方博客还列出 3.20.0 或更高版本。GHES 管理员需要做两件事。立刻升级然后翻 /var/log/github-audit.log搜 push options 里含分号的记录核查是否有未授权的注入痕迹。这个漏洞的触发条件是已认证用户加上对实例上某仓库有 push 权限。门槛并不高。任何拿到一个普通员工账号的攻击者只要这个账号在公司 GHES 上能推代码哪怕只是一个不起眼的内部项目就能拿到整个 GHES 实例的执行权限。而 GHES 上通常跑着公司全部的代码资产、CI 配置、内部凭证。一旦失陷后果很重。这个漏洞还不是 GHES 管理员当下补丁清单里的唯一一条。光看 3.19.5 这一个版本的更新说明同期列出的 HIGH 级漏洞就还有四个CVE-2026-5845、CVE-2026-5921、CVE-2026-4821、CVE-2026-4296。用 SaaS 托管代码补丁打好了自动生效自建 GHES每一个补丁都要管理员自己跟上。逆向太贵这条护城河 AI 正在填平它这次披露还有一个细节被忽视了Wiz 在技术博客里专门解释了这次为什么能找到。他们说GitHub 内部的 git 流水线是大量编译后的闭源二进制以前不是没想过审计而是人工逆向的成本太高做到一半放弃过。这次回来重做是因为工具变了。过去很多闭源软件之所以「相对安全」靠的不是代码本身有多严密而是逆向分析的成本太高没人愿意花那个时间。代码不公开不等于无法被审计只是审计这件事过去在经济上划不来。现在这笔账的算法变了。过去需要资深逆向工程师投入数月的工作用 AI 工具组合下来几周可以做完一轮。Wiz 自己也说这是他们公开记录里第一批靠 AI 在闭源二进制里找到的关键级漏洞用的是 IDA Pro 加 MCP 协议加 LLM 的组合。Wiz Research 博客认为AI 增强的逆向工程工具将在发现需要深入跨组件分析的漏洞类型方面发挥越来越重要的作用。AI 不只在写代码也在拆代码。所有长期靠「闭源没人审」过日子的系统都该重新估一遍自己真实的暴露面。被分号撬开的信任假设回到最初的问题。CVE-2026-3854 出现后GitHub 应急响应教科书级补丁该有的全有没有任何已知的真实攻击。但这次事件留下了三件值得后端工程师认真思考的东西。第一系统设计上的隐患比单点漏洞更难察觉。分隔符协议、跨服务隐式信任、last-write-wins 解析语义这三件事单独存在都不是什么大问题组合在一起就是定时炸弹。任何用分号、竖线或换行传内部元数据的系统今天就该翻一遍代码。第二多租户平台的风险是结构性的不是 GitHub 一家的问题。只要不同用户的数据放在同一台机器上、由同一个服务账户管理这根敏感神经就一直在那里。攻击者一旦拿到执行权限隔离能扛多少取决于那个共享账户的权限边界设计得有多严。第三AI 辅助逆向已经在重写攻防经济账。AI 辅助逆向正在改变攻防的成本结构。下一批被翻出关键漏洞的大概率是那些长期靠「闭源没人审」撑着的企业级软件。GitHub 这次没出事所以更应该认真讨论它。那个被信任了多年的 X-Stat 头在一个分号面前什么都没扛住。