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 可能漏掉了相关修复。

　　据推测，可能是上游的某次代码修改没有被明显标记为安全补丁，导致旧版本未能在第一时间执行。修复被发行版本收录，也依然需要业务方重新构建镜像并完成上线部署，处理图片的服务器才会真正运行安全的代码。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、企业邮箱等入口，意味着潜在的横向移动空间远不止这些。

　　（来源：创科）

　　因此，假设一个底层的图片库漏洞真正用于攻击真实服务器，中间需要攻克大量工程难题。研究人员最初使用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 Claude曾拒绝直接针对远程主机编写的利用程序。研究员的做法是充分利用自己搭建的测试靶机包装成夺旗赛（CTF）的比赛环境，从而引导模型继续辅助调试。

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

　　这提出了一种全新的人机分工形态：安全研究员负责回复攻击路径、判断漏洞价值并搭建验证框架；AI模型则揽承代码逆向、利用编写以及失败结果时的反复。面对漏洞利用链中，最消耗成本的往往不是发现代码里的一个坏样子，而是如何让这个漏洞在特定的CPU架构、发行版编译参数和系统机制下稳定生效。所描述的突破，正是发生在这一意义非凡的专业工时的攻坚阶段。

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

　　援方也在同样尝试用AI辅助排查酒精度报告，但“发现漏洞”和“完成修复”完全是两码事。libheif的维护者在项目安全说明中坦言，仅在2026年1月至8月，项目就发布了37份安全；公告得到了他们的安全中，全部收到了自动化脚本或AI工具生成。但每一份报告，仍然必须由人类开发者逐一复现排查、清除错误报告、编写补丁、回归测试并打标签发布。

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

　　在这次事件中，攻击端使用了克劳德辅助武器化，受波及的账户里则常驻着连接内部权限的Codex。两类工具承担不同的角色，却共同放大了事件的影响力：事先让研究员把一个浅库缺陷迅速成可用的渗透工具，然后则制定着现成的业务权限，把来自外部的指令直接到了内部研发流程下面。代理接入核心代码库与协作平台，这种连接在极大地提高日常生产力的同时，一旦丢失后的潜在破坏面也将保持安静。

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