三黑客攻入OpenAI内部代码库
MIT科技评论 ｜ 2026-09-18

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

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

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

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

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

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

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