GitHub 内部 git 基础设施远程代码执行漏洞 CVE-2026-3854 详解

Wiz Research 在 GitHub 内部 git 基础设施中发现了一个严重的远程代码执行漏洞（CVE-2026-3854），攻击者仅需一个标准 git push 命令即可在 GitHub Enterprise Server（GHES）或 GitHub.com 的后端服务器上执行任意代码。

GitHub 在收到报告后 6 小时内修复了 GitHub.com，并于 2026 年 3 月 10 日发布 GHES 补丁。但截至公开披露时，Wiz 的扫描数据显示仍有约 88% 的 GHES 实例未升级修复。

漏洞概述

CVE-2026-3854 — CVSS 8.7（高危），CWE-77（命令注入）

任何拥有仓库 push 权限的已认证用户，通过注入 git push option 值到 GitHub 内部协议的 X-Stat 头字段，即可在服务端执行任意命令。攻击载体是标准的 git push，不需要任何特殊工具或非标准客户端。

• GitHub.com：RCE 在共享存储节点上。Wiz 确认受影响节点上可访问数百万个其他用户和组织的公开及私有仓库
• GHES：完全接管服务器，包括所有托管的仓库和内部密钥

这是首批通过 AI 辅助逆向工程在闭源二进制文件中发现的关键漏洞之一。Wiz 使用 IDA MCP 工具自动化逆向了 GitHub 的编译二进制文件，重建了内部协议，并系统性地识别了用户输入在整个管线中的影响点。

技术原理

漏洞根源：协议字段解析不一致

当用户执行 git push 时，代码会经过多个内部服务，每个服务由不同编程语言编写。这种多服务架构导致了各组件对共享数据解析和信任的不一致——特别是对内部协议中 X-Stat 头字段的分隔符处理。

X-Stat 头使用特定的分隔符来划分多个元数据字段。问题在于，用户通过 push option 提供的值中可以包含与内部协议相同的分隔符字符，而这些值在被拼接到 X-Stat 头之前没有得到适当的清理。攻击者可以借此注入额外的元数据字段。

攻击链

攻击分三个步骤：

第一步 — 注入 X-Stat 字段。 通过 crafted push option 值注入 rails_env 字段。GHES 的 pre-receive hook 二进制有两个执行路径：当 rails_env 为生产值时，hook 在沙箱内运行；当为其他任何值时，hook 以 git 服务用户身份直接运行，无沙箱隔离，具有完整的文件系统访问权限。

第二步 — 注入 hook 定义。 注入 repo_pre_receive_hooks，其中包含一个 hook 条目，其 script 字段包含路径遍历序列。二进制的路径解析将攻击者的 payload 与目标路径拼接，解析为服务器上任意位置的二进制文件。

第三步 — 在 GitHub.com 上激活。 GHES 上攻击链直接可用（企业模式默认开启）。GitHub.com 上企业模式默认关闭，但该标志同样通过 X-Stat 头传递，因此攻击者可以额外注入一个字段来启用它，从而在 GitHub.com 上实现完整的 RCE。

影响范围

• GHES：所有 ≤ 3.19.1 版本受影响。攻击者可完全接管服务器，访问所有仓库和内部密钥
• GitHub.com：已修复。受影响期间，攻击者可在共享存储节点执行代码，并访问同节点上其他用户的仓库数据

修复版本

建议 GHES 管理员升级到各自版本线的最新补丁版本。GitHub.com 用户无需操作。

时间线

• 2026-03-04：Wiz Research 发现 X-Stat push option 注入漏洞，同日确认 GHES 3.19.1 上的 RCE，并向 GitHub 报告
• 2026-03-04：GitHub 确认接收报告，同日在 GitHub.com 部署修复
• 2026-03-10：CVE-2026-3854 分配（CVSS 8.7），GHES 补丁发布
• 2026-04-28：公开披露

安全建议

GHES 管理员应立即：

1. 升级到修复版本（3.14.24+/3.15.19+/3.16.15+/3.17.12+/3.18.6+/3.19.3+）
2. 审查 git 服务器日志，排查是否有可疑的 push 操作（可能表明已被利用）
3. 审计拥有仓库 push 权限的账户，确认其合法性
4. 在完成升级前，考虑临时限制 push 访问权限仅限受信任用户

来源：Wiz Blog · NVD · GitHub Security Blog