研究人员发现严重远程代码执行漏洞链后，GitLab 用户被敦促安装补丁

爱拍照的老李
爱拍照的老李

爱拍照的老李

2026年7月28日 09:00
湖北

在小说阅读器读本章

去阅读

导读

研究人员通过两个 Oj 解析器漏洞，借助 Jupyter 笔记本的差异对比功能实现了 GitLab 的远程代码执行，该漏洞会影响未打补丁版本中已认证的用户。

Depthfirst 研究人员于7月24日发布了一款针对 GitLab 的远程代码执行漏洞利用工具，该工具利用了 Ruby JSON 解析器 Oj（原生 C 语言实现）中的两个内存损坏漏洞，在 GitLab Puma 工作进程中实现了完整的命令执行。

任何能够推送项目代码并查看提交差异的已认证用户都可以运行该漏洞利用程序。研究人员指出，该漏洞无需管理员权限、无需持续集成（CI）访问权限，也无需受害者参与。

GitLab 已于 6 月 10 日修复了这些漏洞，负责发布版本分类的运维人员没有将其视为紧急修复项。

“该系统识别出了18个优先漏洞，其中包括7个内存安全漏洞。Depthfirst 发布的报告称：‘其中两个漏洞——一个是越界写入漏洞，另一个是堆指针泄露漏洞——在 Oj 中存在了近五年。’‘Oj 是 GitLab 使用的一个底层依赖项，我们结合这两个漏洞，实现了对默认安装的 GitLab 的远程代码执行。’”

这些漏洞于2021年8月8日进入Oj的解析器，在其中停留了1753天。该存在安全漏洞的笔记本路径自2022年7月GitLab 15.2.0版本起随产品发布，直到2026年6月10日才被修复。

攻击路径以 GitLab 的笔记本差异渲染器为起点，这是一个名为 ipynbdiff 的小型内置 gem，可将 Jupyter .ipynb 文件转换为人类可读的差异。当用户打开笔记本文件的提交差异时，GitLab 会将原始仓库字节传递给 Puma 工作进程内的 Oj::Parser.usual.parse。该解析调用是入口点。

“调查是反向进行的：深度优先搜索先在应用程序下方找到了存在漏洞的解析器，随后追溯其调用者，直至用户可控的产品边界。”报告继续说道，“一个真实的请求则沿着这条链以相反方向传递，从 GitLab 的提交差异进入原生 C 代码。”

因为 Oj::Parser.usual 会返回一个在同一 Puma 工作进程中跨线程共享的进程级解析器单例，一旦它被破坏，就会影响该进程中后续的所有解析操作。

第一个漏洞是未检查的嵌套栈溢出。Oj 在解析器对象内部的一个固定 1024 字节数组中跟踪 JSON 嵌套深度。

当攻击者打开超过 1024 个嵌套数组时，Oj 会持续向该缓冲区末尾之外的相邻解析器字段写入单字节集合选择器。

攻击者无法精确控制每个字节——数组始终写入0x01，但可以控制扫描的范围。当嵌套层数足够多时，这个单字节会改变buf.head（解析器的内部缓冲区起始指针），使其向后偏移 127 字节，进入解析器无权访问的内存区域。

此后，一次强制realloc会缓存这个伪造的内部指针，一次 Ruby 数组分配会回收该内存，而数组的元素内容虽被限制为合法的 Ruby 值，但仍受攻击者影响，会将解析器的p->start回调指针替换为指定的地址。

第二个漏洞暴露了地址信息。一个大小为 65,565 字节的超大对象键，其长度从 size\_t 类型被截断为有符号 16 位整数，最终变为 29。Oj 会为完整的键分配堆内存并存储指向该内存的指针，但被截断的长度会让返回路径从内联缓冲区读取 29 字节。这 29 字节中，第 6 至 13 字节恰好包含堆指针。GitLab 会将该指针作为单元格 ID 的一部分渲染到差异对比中。

“返回的第0至5个字节来自外部视图的对齐填充。第6至13个字节是有效的key指针。最后返回的15个字节来自未被外部视图写入的联合存储，可能包含过时的密钥条目内容。这是一次固定的29字节信息泄露，并非任意地址读取：它暴露了该Key条目中已存在的字节，且从未解引用攻击者选定的指针。”报告中写道。“这些偏移量来自经过测试的x86\_64应用程序二进制接口（ABI），因此编译器的布局是该漏洞利用原语边界的一部分。”

掌握一个堆地标后，攻击者通过将自循环指令地址写入p->start并观察哪个解析操作挂起，来探测候选的libc基地址。在全新安装的双工作进程GitLab环境中，ASLR搜索需要五到十分钟。而在成熟且长期运行的实例上，预计耗时为一到两小时。

恢复库基础后，漏洞利用程序在单个diffs\_stream请求中链接了两个原语。

同一提交中的两个按字典序排列的笔记本文件承载了各个阶段：第一个笔记本文件设置回调指针，引发异常以避免立即执行，并让GitLab继续流式传输差异。第二个笔记本文件的旧侧在同一Puma工作进程中触发p->start，该操作通过两个libruby小工具跳转至system()，且攻击者的命令位于正确的寄存器中。命令以git（即Puma背后的账户）身份运行，这使得攻击者能够获取应用程序可访问范围内的源代码、Rails密钥、服务凭证以及所有内部服务。

“攻击成功后，攻击者以运行 GitLab Puma 工作进程的 git 用户身份执行了命令。其实际影响范围取决于部署的隔离情况，但可能包括应用程序可访问的代码仓库数据、Rails 密钥、服务凭证以及内部服务。”报告总结道：“这可能导致源代码泄露、凭证被盗、代码仓库被篡改、持久化控制或横向权限访问。”

GitLab 社区版（CE）和企业版（EE）的 15.2.0 至 18.10.7、18.11.0 至 18.11.4 以及 19.0.0 至 19.0.1 所有版本均受影响，涵盖所有版本层级。15.2 之前的版本在该路径下使用了不同的 JSON 解析器，不存在此漏洞。

15.2 至 18.9 版本不在 GitLab 安全维护的补丁序列内，不会收到回溯修复——这些安装版本需升级至受支持的版本。

对于 Helm 和 Operator 部署，相关版本为运行 Puma 的 Webservice 镜像中的 GitLab 版本，而非图表版本。请升级至 18.10.8、18.11.5 或 19.0.2 版本。depthfirst 或 GitLab 均未验证过仅通过配置的解决方法。

新闻链接：

https://securityaffairs.com/196062/hacking/gitlab-users-urged-to-patch-after-research-reveals-critical-rce-chain.html