三个黑客花不到3000美元，用Claude攻入了OpenAI内部代码库

7 月 25 日，OpenAI 内部代码仓库 openai/openai 收到了一条编号为 #1186742 的拉取请求（PR）。安全公司 Hacktron 随后披露，这条指令的实际发起者是三名外部安全研究员，但执行操作的，却是某位 OpenAI 员工账户里的 Codex。研究员让 Codex 提交了一条无害的 PR，以此证明他们已经能通过员工账户直接操作内部代码仓库；他们同时表示，测试过程中并未查看任何敏感源代码。

近日，《华尔街日报》报道了这起几名研究员借助 Claude 黑入 OpenAI 内部的安全事件，引发广泛关注。事件发生在近两个月前，研究者当时只用了不到 72 小时，就一路黑到了 OpenAI 的内部代码仓库。

而这起事件的源头，仅仅是 OpenAI 官方社区论坛里的一张图片。研究员先是利用图片处理组件的内存漏洞拿到了论坛服务器的控制权，接着借助 OpenAI 单点登录系统的配置缺陷，接管了员工的 ChatGPT 和 Codex 账户。而由于该员工此前已经给 Codex 绑定了 GitHub 权限，最终让攻击者顺着这条链路，一路走进了内部代码仓库。

（来源：Hacktron）

Hacktron 团队是从 7 月 23 日开始审计论坛所用的 Discourse 系统的。通常情况下，用户上传普通格式图片后，Discourse 会调用 FastImage 来校验文件；但遇到 HEIC 或 HEIF 格式时，由于 FastImage 无法识别，系统就会将文件转交给 ImageMagick 进行格式转换，并最终由底层的 libheif 库来负责解码。研究员注意到了这条链路的风险：外部用户可以随意上传文件，而负责解析该格式的底层程序却存在内存安全隐患。

表面上看，上传图片只是把文件存入服务器，但后台实际需要先将其打开，读取尺寸、图层、像素排列等元数据，并渲染出可供浏览器展示的版本。HEIF 格式允许组合多种图像结构，这要求解码器在处理时频繁核对文件中的数据声明。

如果攻击者精心构造恶意数据，诱使程序发生内存越界读写，上传图片就会演变成在服务器上执行任意代码的突破口。libheif 项目的安全说明也曾详细记录过，这种复杂的图像格式给解析器边界检查带来的巨大挑战。

（来源：Hacktron）

一个漏洞从上游代码流入实际的生产环境，往往还要经过 Linux 发行版打包和 Discourse 容器镜像构建两个环节。Hacktron 发现，当时论坛镜像里的 libheif 恰恰漏掉了相关修复。

据推测，可能是上游的某次代码修改没有被明确标注为安全补丁，导致旧版本软件包未能在第一时间跟进。即便修复被发行版收录，也依然需要业务方重新构建镜像并完成上线部署，处理图片的服务器才会真正运行安全的代码。Debian 随后发布的安全公告中，就记录了针对 libheif 多个隐患的集中更新。

研究团队表示，他们正是通过图片上传，在 OpenAI 的 Discourse 运行环境中实现了远程代码执行（RCE），并拿到了论坛的管理权限。Discourse 在 7 月 28 日发布的安全公告中确认，libheif 的缺陷确实能通过图片上传触发远程代码执行。为此，Discourse 重新打包了容器镜像，并给图片处理流程增加了额外的隔离保护。至此，整条攻击链路的第一道防线被攻破。

第二步发生在身份认证系统。OpenAI 社区论坛支持直接使用 OpenAI 官方账户登录。Hacktron 将已经获取的论坛服务器权限，与 OpenAI 单点登录（SSO）中的一处配置缺陷结合，成功渗透进了多名员工的 ChatGPT 账户，并拿到了其中一人的 Codex 访问权。

论坛是由 Discourse 搭建的独立服务，用户账户却归属于 OpenAI 主站；正是这处位于 OpenAI 一侧的认证缺陷，导致外围论坛的失守直接波及到了核心员工账户。目前，该缺陷的具体技术细节尚未完全公开。

进入 Codex 后，研究员面对的已经是该员工配置好的现成工作环境。OpenAI 的企业使用说明显示，获得仓库授权的用户，可以通过绑定的 Codex 直接创建任务并推送代码 PR。

这项功能原本是为了方便工程师将日常开发工作委托给 AI 代理（Agent），但在账户被外部接管时，这项现成的授权同样允许攻击者命令 Codex 替他们向内部仓库提交代码。Hacktron 披露的实际操作止步于 GitHub，但他们也提到，该账户同时关联了 Slack、企业邮箱等入口，意味着潜在的横向移动空间远不止于此。

（来源：Hacktron）

实际上，要把一个底层的图片库漏洞真正用于攻击真实服务器，中间需要攻克大量工程难题。研究员最初使用 Claude Opus 4.8 扫描 Discourse 镜像里的 libheif，寻找被遗漏的补丁，并尝试生成初步的利用脚本（Exploit）。但这套脚本只能在关闭 ASLR（地址空间布局随机化）的环境下起效。

在实际生产中，ASLR 会在每次程序启动时打乱关键内存地址；一个只能在关闭防护时跑通的演示，距离稳定控制默认配置的服务器还有很大差距。Hacktron 表示，团队反复尝试了多轮会话，都没能跨过这个门槛。

转机出现在 7 月 24 日，当天Anthropic 发布了 Claude Opus 5。换用新模型后，研究团队在几小时内就在本地 Mac 上跑通了首个可用版本，随后进一步要求模型针对 Discourse 实际运行的 x86-64 架构和特定的内存分配器进行适配。

接着，团队构建了一个自动化的任务反馈闭环，让 Claude 在他们自建的 Discourse Cloud 靶机上持续迭代测试。研究员表示，模型最终成功在该实例中完成了稳定的代码执行；他们随后使用生成的脚本，顺利完成了对 OpenAI 真实论坛环境的验证。

在这个过程中，也可以看到大模型的内置安全限制是如何被绕过的。Hacktron 提到，Claude 起初曾拒绝直接针对远程主机编写利用程序。研究员的做法是将自己搭建的测试靶机包装成夺旗赛（CTF）的比赛环境，以此引导模型继续辅助调试。

归根结底，测试环境如何定义、产出的成果何时打向真实目标，依然由人来把控。模型虽然拦下了直接打向远程服务器的请求，但在受控测试环境下生成的代码，依然能被人工无缝迁移到真实的攻击目标上。

这呈现出一种全新的人机分工形态：安全研究员负责梳理攻击路径、判断漏洞价值并搭建验证框架；AI 模型则承揽代码逆向、Exploit 编写以及面对失败结果时的反复微调。在漏洞利用链中，最消耗成本的往往不是发现代码里的一个坏味道，而是如何让这个漏洞在特定的 CPU 架构、发行版编译参数和系统防护机制下稳定生效。Hacktron 所描述的突破，恰恰发生在这一极其耗费专业工时的攻坚环节。

从最初开始分析论坛组件，到最终让 Codex 提交内部 PR，团队表示整个过程耗时不到 72 小时。Hacktron 还披露，这项包含三名研究员、代号为“HEIF Heist”的多目标挖掘项目历时约两个月，调取模型的总花费还不到 3,000 美元。随着模型能力的提升，极小规模的安全团队也能并行承担复杂的漏洞分析与环境适配工作，以往限制攻击规模的人力与资金门槛正在迅速降低。

防守方同样在尝试用 AI 辅助排查隐患，但“发现漏洞”和“完成修补”完全是两码事。libheif 的维护者在项目安全说明中坦言，仅在 2026 年 1 月至 8 月期间，项目就发布了 37 份安全公告；如今他们收到的安全报告中，绝大多数都由自动化脚本或 AI 工具生成。但每一份报告，依然必须由人类开发者逐一复现排查、剔除误报、编写补丁、回归测试并打标签发布。

这个被全球广泛引用的基础图形库及相关依赖，其核心维护工作长年由一名独立开发者利用业余时间无偿承担。AI 成倍加速了漏洞被挖出的速度，但现实世界中负责兜底修复的吞吐量，却牢牢受制于有限的人力。

在这次事件中，攻击端使用了 Claude 辅助武器化，受波及的员工账户里则常驻着连接内部权限的 Codex。两类工具承担不同角色，却共同放大了事件的影响力：前者让研究员得以把一个底层库缺陷迅速打磨成可用的渗透工具，后者则携带着现成的业务权限，把来自外部的指令直接递送到了内部研发流程深处。随着越来越多的企业让 AI 代理接入核心代码库与协作平台，这种连接在大幅解放日常生产力的同时，也在悄然拓宽账户一旦失守后的潜在破坏面。

7 月 25 日，研究员在通过 PR 验证权限后立即停手，并向 OpenAI 提交了漏洞报告。Hacktron 公布的记录显示，OpenAI 当晚便确认修复了身份认证层面的漏洞；Discourse 随后也收到了通报，并于 7 月 28 日发布了安全更新。Hacktron 表示，OpenAI 最终在 9 月 1 日向其发放了 6,500 美元的漏洞赏金，奖励他们发现单点登录系统的缺陷；由于外围论坛不属于赏金覆盖范围，因此未计入在内。

参考资料：

1.https://www.hacktron.ai/blog/hacking-openai

运营/排版：何晨龙

注：封面/首图由 AI 辅助生成