Depthfirst 报告称,在累计下载量达 86 亿次的 Ruby 项目中发现 105 个漏洞

这家人工智能安全初创公司表示,在相关漏洞使得自托管的 GitLab 出现代码执行后,维护者已确认了 62 项发现。

By · Published

Primary source: X

Why it matters

Depthfirst's findings show how native code can undermine a memory-safe language, while the GitLab exploit tests whether AI security agents can connect buried bugs to reachable product risk.

Illustration of Depthfirst exposing 105 flaws in widely used Ruby projects, showing fragmented code and warning icons tied to self-managed GitLab.

Qasim Mithani, Andrea Michi (@andreamichi), 和 Daniele PeritoDepthfirst 在 7 月 27 日表示,其 AI 安全平台在 34 个 Ruby 项目中发现并验证了 105 个漏洞,这些项目的包累计下载量超过 86 亿次。

该数据来自对大约 40 个 Ruby gem 项目的审查,Depthfirst 重点关注包含本地 C 扩展的包。在其 技术报告 中,Depthfirst 表示维护者已确认了其中 62 项发现。这个区分很重要:头条数字是 Depthfirst 验证的总数,而受影响项目的确认只覆盖了更狭窄的子集。

这项研究起源于 Depthfirst 之前发现的两个内存损坏漏洞,研究人员将它们串联成可在自建 GitLab 部署上实现远程代码执行的链。更广泛的扫描为 Depthfirst 提供了对其产品核心前提的具体检验:专门的 AI 代理可以从检测可疑代码发展到重现漏洞、追踪到下游应用并提出修复方案。

Mithani 此前在 AWS 构建过面向开发者和安全的产品,并在 Databricks 负责基础设施工作。Perito 是 Faire 的联合创始人,曾参与 Cash App 的创始团队并在 UC Berkeley 开展安全研究。Michi 曾担任 Google DeepMind 的研究工程负责人,参与过对 Gemini 和 AlphaDev 的强化学习工作。他们的背景解释了 Depthfirst 决定训练专门的安全系统,而不是把应用安全当作套在通用模型上的另一个提示的原因。

Ruby 之下的不安全层

Ruby 在应用层自动处理内存,为开发者屏蔽了许多 C 和 C++ 中常见的分配与指针错误。包含本地 C 扩展的 Ruby gems 会跨越这一边界。这些扩展可能引入固定缓冲区、不安全的整数转换、陈旧指针,以及生命周期不再由 Ruby 垃圾回收器正确管理的对象。

Depthfirst 表示内存安全违规约占其发现的 61%。受影响的包包括解析器、数据库驱动、Web 服务器、加密库、图像处理工具、网络组件,以及对本地库的绑定。

一个漏洞影响了广泛使用的 XML/HTML 解析器 Nokogiri。根据 Depthfirst 的分析,该漏洞在 2009 年进入 Nokogiri,并一直存在直到 2026 年 6 月 18 日发布的 1.19.4 版本。该缺陷在边界检查期间将一个 64 位数组索引转换为 32 位整数,然后用原来的 64 位值访问内存。因此,一个足够大的负索引可能会通过验证并触发越界读取。

另一个发现影响了 concurrent-ruby,这是 Rails 和其他 Ruby 软件使用的并发库。读锁计数器和写锁标志共用同一个整数。经过 32,768 次重复获取读锁后,计数可能溢出到表示写锁所有权的位,导致代码在不阻止其他读取者的情况下报告独占访问。

Depthfirst 表示其代理在人工审核之前生成了触发输入、复现脚本以及诸如 AddressSanitizer 输出之类的证据。这些发现通过其 Open Defense Initiative 流出,该计划为广泛部署的开源项目维护者提供积分,并将发现输送到 Depthfirst 的 Supply Chain 产品中。

从 Oj 漏洞到 GitLab 代码执行

最具影响力的结果来自 Oj,这是一个部分用 C 实现的高性能 JSON 解析器。Depthfirst 的系统在 Oj 中优先排查了 18 个潜在漏洞,包括 7 个内存安全问题。研究人员将一次越界写与一次堆指针泄露结合,生成了一条 远程代码执行链

GitLab 在呈现 Jupyter Notebook 文件不同版本之间的差异时使用了受影响的 Oj 解析器。根据 Depthfirst 的说法,一个能够推送提交并查看提交差异的已验证项目成员可以将精心构造的 notebook 数据放入仓库,并将这些字节在 GitLab 的 Puma worker 内路由到 Oj。

Depthfirst 表示该链影响了 GitLab Community Edition 和 Enterprise Edition 的 15.2.0 到 18.10.7、18.11.0 到 18.11.4,以及 19.0.0 到 19.0.1 版本。GitLab 在 6 月 10 日的补丁发布 中将 GitLab 18.10.8、18.11.5 和 19.0.2 中的 Oj 升级到 3.17.3。GitLab 建议受影响的自建安装立即升级,并表示 GitLab.com 已经打过补丁。Depthfirst 还发布了 概念验证代码

这条 GitLab 漏洞链强化了 Depthfirst 商业模式的理由。一个仅仅标注不安全 C 代码的扫描器会把是否能从产品接口到达漏洞的判断留给安全工程师。Depthfirst 将易受攻击的解析器沿着 GitLab 的 notebook-diff 功能追溯,并证明了从仓库可控数据到代码执行的路径。

投资者已经对这种方法投入了巨大赌注。Depthfirst 在 3 月 31 日宣布了由 Meritech Capital 领投的 8000 万美元的 B 轮融资,Forerunner Ventures、The House Fund、Accel、BoxGroup、Liquid 2 Ventures、Alt Capital 和 Mantis VC 参与。本轮之前公司在一月完成了由 Accel 领投的 4000 万美元 A 轮,该轮融资使 Depthfirst 披露的融资总额达到 1.2 亿美元。

此次 Ruby 研究现在为 Mithani、Michi 和 Perito 提供了超越客户指标和基准得分的证据。成熟的开源包仍然包含可能存活多年的漏洞,而低级依赖中的一个缺陷可以在若干层下游演变为应用级别的妥协。Depthfirst 押注的是:构建为追踪整条路径的安全代理将成为软件供应链本身的一部分。

Reader comments

Conversation for this story loads after sign-in.