Michael Johnson即使你已经更新了终端中的 Git，工作也还没完成：某些应用和构建环境会运行自己的副本。2026 年 11 月 10 日，Git 项目发布了六项漏洞的修复，问题涵盖递归克隆时执行代码以及合并时内存损坏。因此，需要检查每个会处理仓库或其内容的环境，而不能只看 shell 中执行 git --version 的结果。
此次更新有哪些变化
修复已包含在 Git 2.56.1 中，并移植到受支持的分支：2.55.1、2.54.1、2.53.1、2.52.1、2.51.3 和 2.50.2。此次更新修复了 Git 不同部分中的六项问题，涉及路径、链接、签名、二进制补丁、合并和导入流。GitHub 于 11 月 10 日发布了漏洞分析及更新建议；Git 2.56.1 发布说明列出了这一系列版本修复的 CVE。
实际而言，需要更新三个位置使用的 Git：工作电脑、自动化环境，以及内置独立 Git 构建版本的应用。最后这一点很容易被忽略：更新系统软件包，并不会自动改变每个客户端或构建镜像中的版本。
为什么递归克隆值得关注
最直观的攻击链始于递归克隆不可信仓库。由于路径长度被截断，超长路径可能以一个名称通过检查，随后却以缩短后的名称写入磁盘。在 Git 描述的场景中，这使攻击者能够将子模块的 .git 文件替换为指向某个目录的符号链接，而该目录中包含恶意配置或钩子。之后 Git 访问该内容时，可能会执行攻击者指定的代码。
实践中需要注意：这需要经过专门构造的仓库和相应操作。经常使用 --recurse-submodules 参数从外部来源克隆项目的团队，应优先更新客户端和自动化环境。修复会在路径长度遭到截断之前拒绝过长路径。
Git 处理不可信数据的其他环节
另一项问题出现在通过 Git protocol v2 克隆空仓库时。服务器可能传回一个 HEAD 引用，其分支名包含目录遍历组件；之后更新分支的操作可能会将文件写到预期引用目录之外。修复后的 Git 会检查这一目标，以及通过协议收到的其他引用名称。
另有漏洞影响合并和补丁操作。处理签名时，固定大小的数组最多只为两份签名预留空间；经过特殊构造、包含更多签名的消息可能导致越界写入并破坏内存。应用二进制补丁时，大小检查依据的是原始表示，而压缩数据解压后可能膨胀到大得多的体积。现在，Git 会在处理之前检查声明的未压缩大小。
大型合并也可能导致计算所需缓冲区大小时发生溢出，继而越界写入。这也会影响合并不可信内容的托管平台和应用。最后，git fast-import 的三项功能新增了对输入流命令的限制：rewrite-submodules-from 和 rewrite-submodules-to 可能读取任意文件，而 export-pack-edges 可能创建文件或向现有文件追加数据。现在，除非明确指定 --allow-unsafe-features 标志，否则这些功能会被禁用；该标志仅应与可信的流生成器搭配使用。
在哪里查找独立的 Git 副本
开发者可以先盘点各个启动 Git 的来源。检查终端中的版本，并使用 IDE 和桌面 Git 客户端自带的更新检查功能。然后检查会执行 clone、merge、应用二进制补丁或运行 fast-import 的 CI 镜像、容器、runner 和服务器任务。主机上安装了最新版 Git，并不能保证应用实际调用的就是它。
在组织中，除了核对源镜像，也应检查已经部署的工作环境：持久化 runner 或内部服务可能在基础镜像更新后，仍保留着旧的二进制文件。GitHub 指出，GitHub Enterprise Server 的修复版本为 3.19.15、3.20.11、3.21.9 和 3.22.4。该公司表示，已在 github.com 和 GitHub Enterprise Cloud 上部署修复，包括采用数据驻留选项的环境。包含已修复 Git 版本的 GitHub Desktop 和 GitHub Copilot app 版本正在协调发布；Codespaces 和 GitHub Actions 的修复版本也尚待推出。
更新前如何降低风险
如果无法立即安装修复，请暂时限制对不可信数据的操作：只从可信服务器克隆仓库，避免递归克隆未经检查的项目，不要合并其内容，也不要应用从这些项目获得的二进制补丁或 fast-import 流。这些措施能减少接触特定易受攻击场景的机会，但不能替代更新。
最重要的实践结论很简单：应该在程序实际运行 Git 的地方查找并安装修复。终端中的命令只是其中一个位置；开发客户端、CI 和仓库处理服务都需要单独检查。
