文章总结： GitLab在6月10日通过升级Oj依赖修复了两个内存安全问题，但未列入安全修复表，导致部分团队忽略。公开PoC于7月24日发布，攻击需认证用户且有项目提交权限。建议立即确认版本、升级到最新补丁、缩小入口、检查异常活动并准备凭据轮换。同时应改进发布流程，将核心依赖升级纳入安全评估。 综合评分： 88 文章分类： 漏洞分析,安全运营,实战经验,漏洞预警,安全建设

GitLab 六周前已经修了，公开 PoC 后为什么还要重新排查

原创

tcode tcode

字节脉搏实验室

2026年7月27日 10:07 北京

在小说阅读器读本章

去阅读

    depthfirst 披露，两处 Oj JSON 解析器内存安全问题可以通过 GitLab 的仓库内容渲染路径组合，最终让具备项目提交权限的普通认证用户在自建 GitLab 上执行命令。GitLab 在 6 月 10 日发布的 18.10.8、18.11.5 和 19.0.2 中引入 Oj 3.17.3，修复了相关问题。

    问题在于，这项变更没有以独立安全条目出现在当时发布说明的安全修复表中，而是以 Oj 依赖升级出现在缺陷修复部分。它没有 CVE，也没有 CVSS 分数。只依据“安全修复”栏目安排优先级的团队，可能合理地错过了它。

    “需要登录”并不等于风险低

    公开研究给出的前提是攻击者拥有可登录账号，并能向项目提交内容。这个条件看起来比未认证攻击严格，却不能被简化成“只有内部管理员能利用”。

    很多 GitLab 实例服务于外包、供应商、实习生、开源协作者和自动化账号；有些实例允许较宽松的注册或项目邀请。即使账号本身权限不高，一次密码复用、令牌泄露或离职账号未回收，也可能满足入口条件。

    更重要的是，GitLab 不是单一代码仓库。应用进程可能接触源码、Rails 密钥、服务凭据、CI/CD 数据，以及它能够访问的内部服务。命令以 git 服务账户权限运行，不代表影响只停留在一个普通 Linux 用户；真正后果取决于该账户能读取什么、网络能到哪里、Runner 与生产凭据如何分隔。

    先确认你检查的是应用版本，而不是外层标签

    自建 GitLab 有 Omnibus、源代码、Helm Chart 和 Operator 等多种部署方式。研究团队特别提醒，Helm 和 Operator 环境要核对 Webservice 镜像中实际运行的 GitLab 应用版本，不能只看 Chart 或 Operator 版本号。

    受影响范围包括 GitLab CE/EE 15.2.0 至 18.10.7、18.11.0 至 18.11.4、19.0.0 至 19.0.1；首个修复版本分别是 18.10.8、18.11.5 和 19.0.2。所有授权层级都在范围内。GitLab.com 已在 6 月 10 日版本中修复，GitLab Dedicated 客户按官方说明无需自行处置。

    首个修复版本只是判断线，不是今天的推荐目标。仍在 15.2 至 18.9 等停止安全维护分支的实例，不能期待旧分支得到回补，应迁移到当前受支持版本。已经越过首个修复版本的团队，也应核对实际镜像、所有节点和回滚环境，防止主节点升级而灾备或旧镜像仍可被调度。

    公开 PoC 出现后，补丁任务要升级成一次证据检查

    第一步是版本确认。记录每个自建实例、Webservice 副本、灾备环境和临时测试环境的实际应用版本与镜像摘要。版本不明的实例按未修复处理，直到证据补齐。

    第二步是快速升级。直接升级到当前受支持的最新补丁版本，不要仅停在首个修复版本。无法在短时间升级时，应向 GitLab 获取与部署相匹配的临时指导；公开研究和官方资料都没有提供经过验证的通用配置型绕过措施。

    第三步是缩小入口。暂停不必要的开放注册，复核外部协作者和自动化账号，收紧对敏感项目的提交权限。这个动作只能降低利用机会，不能替代升级，也不能被标记为永久修复。

    第四步是检查活动。围绕补丁前窗口查看异常项目创建、短时间内反复提交或查看特殊文件差异、Puma 进程异常、git 账户产生子进程、异常出站连接和关键文件读取。不要在告警规则里包含公开 PoC 的完整结构；以行为和访问序列为主，既减少复制攻击细节，也更能覆盖变体。

    第五步是准备凭据处置。如果发现应用进程被劫持的证据，应在隔离和证据保全后，轮换 GitLab 应用密钥、服务令牌、CI/CD 变量及可从该主机访问的下游凭据。先盲目轮换、却让攻击者继续停留，会导致新凭据再次暴露。

    为什么发布流程也需要复盘

    这次事件还有一个管理问题：修复真实存在，却没有进入安全修复表。企业如果把升级策略完全绑定 CVE、CVSS 和厂商安全标题，就会漏掉“普通依赖升级中包含安全价值”的情况。

    更稳妥的规则是把互联网暴露的核心研发平台纳入持续补丁节奏。即使一次发布说明没有高危编号，也应在可控窗口升级最新补丁，并让安全团队订阅研究方和上游依赖公告。CVE 是信息索引，不是风险产生的开关。

    同时，厂商发布说明应成为升级输入，而不是唯一证据。对 GitLab 这类身份、源码和发布链汇聚的平台，落后多个补丁版本本身就是风险信号。等到公开利用代码出现再启动资产盘点，通常已经把最宝贵的准备时间用完了。

    平台团队可以把这次遗漏转成一条长期控制：为所有自建实例设置最低受支持版本和最长补丁延迟，资产责任人每月确认实际应用版本，而不是只确认服务器在线。Helm、Operator、灾备和临时测试环境都要进入同一资产视图；旧镜像超过保留期后禁止再次部署。安全团队则应对核心依赖升级建立关注清单，发布说明出现解析器、身份组件或原生扩展更新时，即使没有 CVE，也触发一次轻量风险评估。

信息边界

    已确认的是受影响版本、修复版本、认证与项目提交权限前提，以及公开概念验证已经出现。depthfirst 表示不知道存在真实环境中的利用活动；这基于其可见范围内没有报告，并不等同于全网不存在利用。当前公开信息也没有独立 CVE。

结语

    对 GitLab 管理者，今天最重要的问题不是“这个漏洞为什么没有 CVE”，而是“我们是否能证明所有实际运行的 Webservice 都已升级，并能解释补丁前发生过的异常活动”。

    六周前的补丁没有过期，公开 PoC 只是让欠下的升级债突然有了更明确的成本。确认真实版本、升级受支持分支、检查项目与进程行为，再根据证据决定是否轮换凭据，这四步比追逐一个编号更有价值。

参考来源

• depthfirst：GitLab Oj Spill（PoC 于 2026-07-24 公开，页面未标明时区）

• GitLab：Patch Release 19.0.2, 18.11.5, 18.10.8（2026-06-10）

• Oj：v3.17.3 Release（2026-06-04 20:27，GitHub 页面未显示时区）

• The Hacker News：Researcher Publishes GitLab RCE PoC（2026-07-25 15:44:26 +05:30；北京时间 18:14:26；2026-07-26 更正）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：字节脉搏实验室 tcode tcode《GitLab 六周前已经修了，公开 PoC 后为什么还要重新排查》