2026年7月25日，我们把两个严重漏洞串联，接管了多名OpenAI员工的ChatGPT账户，得以访问内部代码库和大量连接器。为证明权限且不接触敏感信息，我们用员工的Codex在内部单体仓库openai/openai提交了PR #1186742。漏洞链从libheif、Debian、ImageMagick、Discourse、OpenAI论坛延伸到OpenAI SSO、ChatGPT／Codex、GitHub和内部仓库。直到两个月前，任何登录community.openai.com的用户或OpenAI员工都可能被接管ChatGPT和Codex账户。

2026年7月25日，我们将两个严重漏洞串联，攻陷了多名 OpenAI 员工的 ChatGPT 账户。借助这些账户，我们得以访问 OpenAI 内部代码仓库及潜在的大量其他连接器。

为证明确实获得所声称的访问权且避免接触敏感信息，我们利用该员工的 Codex 在 OpenAI 内部单体仓库 openai/openai 中发起了拉取请求 #1186742。

利用链： 1. libheif 图片解码器 2. Debian 缺失安全向后移植补丁 3. ImageMagick 使用 libheif 4. Discourse 图片上传 5. OpenAI 论坛 community.openai.com 6. OpenAI SSO 身份缺陷 7. ChatGPT / Codex 账户访问 8. GitHub 已连接的集成 9. OpenAI 内部仓库

直到两个月前，任何登录 OpenAI 帮助论坛（community.openai.com）的用户或员工，其 ChatGPT 和 Codex 账户都可能被接管。由于人们可将各种服务连至 Codex 和 ChatGPT，理论上能访问的范围极广，包括 GitHub、Slack 和邮件。

从初始发现到访问 OpenAI 仓库，整个过程不到 72 小时。

我们立即向 OpenAI 和 Discourse 报告初始漏洞并配合修补。OpenAI 支付了 6500 美元赏金。

背景

几个月前，我们开始研究前沿 AI 公司以寻找漏洞，发现了 OpenAI 身份基础设施中的 SSO 配置错误，以及其社区论坛中 libheif 的远程代码执行漏洞。此后研究扩展为“HEIF Heist”项目，跨时数月追踪 libheif 在 Slack、Meta、GitHub Enterprise、Ruby on Rails 及 Next.js 等 Node.js 框架中的影响。大量广泛使用的软件都依赖这个图像处理库。

警告：若你自托管 Discourse，请立即重建安装。旧 Docker 镜像可能含易受攻击的 libheif，允许通过图片上传执行代码。在 /var/discourse 运行 git pull 然后 ./launcher rebuild app；仅网页更新可能无法替换底层镜像。Discourse 托管客户已修复。

OpenAI 用 Discourse 搭建论坛，允许通过 auth.openai.com “用 OpenAI 登录”。我们确信攻陷论坛可借该身份流程通向更广的 OpenAI 服务。为验证，我们首先需要在 Discourse 论坛获得远程代码执行。虽然 Discourse 应用本身不易攻破，我们决定从其依赖下手。

libheif 中的堆缓冲区溢出

7月23日，我们审查 Discourse 图片上传管道，发现 HEIC/HEIF 文件因 FastImage 不支持而交给 ImageMagick 的 magick 命令转换，将底层 libheif 解析器暴露给攻击者文件。

我们用 Opus 4.8 检查 Discourse Docker 镜像中的 libheif 包，发现某些安全修复未向后移植，导致 HEIC 解码时堆缓冲区溢出及越界读写。相关代码上一年已在上游修改，但未记为安全修复且无 CVE，导致 Debian 12/13 未及时收补丁。Discourse 基于 Debian 12 装了易受攻击的 1.19.7；Debian 13 当时也是易受攻击的 1.19.8。Debian 后来于 2026 年 8 月 8 日发安全更新。

7月24日，我们用 Opus 4.8 开发了禁用 ASLR 下可用的利用，但启用 ASLR 的多个会话均未成功。

Opus 5 发布

当晚 Anthropic 发布 Claude Opus 5。新会话先在 3 小时内产出本地 Mac 的 ARM64 利用，随后移植到 Discourse 的 x86-64 和 jemalloc 配置。

7月25日凌晨 6 点，我们通过图片上传确认本地 RCE，并将 Claude 置于自主 /goal 循环攻击自己的 Discourse Cloud 实例（经 rce.ee/ctf-forum 代理伪装 CTF 目标，因 Opus 拒为远程写利用）。上午 10 点，代理已实现 RCE 并读取 /etc/hosts 证明。利用该脚本，我们在 OpenAI 实例上获得 RCE。

确认无交互接管论坛成员账户后，我们立即报告 OpenAI，并接管了一名连着 OpenAI Github 组织的员工账户。为证影响不触敏感代码，我们令其 Codex 在内部仓库发 PR 后停止测试。

我们用证明更新 BugCrowd 提交并警报 OpenAI，同时向 Discourse 的 HackerOne 交报。Discourse 周六收报、周日回复、周一修复，并立即沙箱化 ImageMagick。

需强调，提权漏洞非 Discourse 特有，而是 OpenAI SSO 问题将论坛失陷转为 ChatGPT/Codex 访问。任何用 OpenAI SSO 的服务若被攻陷都同效——Discourse 仅是证明路径之一。

发现这些漏洞的成本

Discourse 和 OpenAI 攻击令代理耗时数天，人类仅几小时。整个“HEIF Heist”项目两月、token 花费不足 3000 美元、三人完成，适配新公司通常一两天。

模型能力递增明显：Opus 4.8 多个会话无法产出启用 ASLR 利用；Opus 5 几小时内成功；到 GPT-5.6 Sol 时，我们在仅知目标存在漏洞下完成利用。

测试从图片上传始，将内存破坏转可靠泄露或 shell，常不知 libheif 版本等。AI 近乎盲打，一两天适配每家公司。除 Shopify 外无公司检测到活动，即便数千图片发出、处理器崩溃。

代码执行落入沙箱时，模型还协助提权、横向移动和绕防。这非完全自主，人类引导仍重要，但小团队工作量剧增。

后记

软件长期受益于“复杂即安全”：代码甚至漏洞可公开，但转可靠利用需稀缺专家经验、大量时间和目标知识。这非真安全边界，却保护普通公司。AI 正将稀缺经验转算力，消除保护。曾需团队数月的工作压缩至数天。

安全假设须赶上攻击者能力。威胁模型应考虑当今利用经济学，而非过时假设。

Hacktron 使命是在恶意者前发现消除广泛信任软件漏洞以保护互联网。我们延续跨前沿实验室研究，若你负责安全，望合作。

受影响版本与补丁

HEIF Heist 不绑单一版本，针对跨多发布系列（1.19.x、1.20.x、1.22.x、1.23.x）漏洞生态。缺最新上游补丁的部署均可能易受攻击。

• 更新上游： 通过发行版安全渠道或上游装最新 libheif 和 libde265 包。截至 2026 年 9 月 14 日，最新 libheif 安全版 v1.23.4；v1.23.2 已被取代。发行版包可能旧号带移植修复，需查公告。
• 纵深防御： 鉴于格式复杂，未来缺陷很可能。不需时应禁不受信 HEIF/AVIF 解码，或隔离管道至临时沙箱。ImageMagick 策略支持限格式和资源。

致谢

感谢 Sudanshu Rajhbhar 技术协助，及 Zayne Zhang、Fabian Faessler、Robert Chen、Jessica Ruan 校对反馈。

讨论气氛一半是技术复盘，一半是愤怒：多数人揪住 6500 美元赏金不放，认为它和潜在的源码、模型权重与仓库访问权限完全不成比例；另一条分歧主轴是 AI 代理在真实攻防中的表现，有人惊叹其迭代速度，有人担心只要模型确信"这是场比赛"，它就会做几乎任何事。

赏金低到像是侮辱，根本没反映真实风险

• 有人认为这个漏洞若流入黑市，价值可能是数百万美元级别，正常的安全报告或加密合约漏洞赏金平均也在十万到千万美元之间（较多人）
• 对一家刚遭遇潜在完整源码泄露的近万亿美元公司来说，这个数额被认为是安全团队价值的直接体现（较多人）
• 也有人追问：Discourse 作为漏洞源头，为什么没有另外支付赏金（少数人） > 黑市上这种东西大概值六百五十万美元，甚至更多。（@kerenskiy）
• 还有一条玩笑问那三千美元 token 开销有没有换来一件免费 T 恤，基本代表了社区对赏金的情绪（少数人）

问题不在某个库的偶发 bug，而在攻击面本身

• 有评论指出未加沙箱的 ImageMagick 从 PHP 时代起就是安全噩梦，沙箱也不是万灵药，只是把利用难度推高一档；长此以往也许该把所有解析器换成至少和 Wuffs 一样安全的实现（较多人）
• 读者读完 libheif 补丁后指出，问题出在图像叠加层的边界检查上：容器可以包含多张图并组合输出，还支持旋转、裁剪、alpha 通道、缩略图等论坛根本用不到的功能，攻击面远大于传统 JPEG（较多人） > 与其等下一个图形库再爆漏洞，不如保持简单：服务端只收普通 JPEG，真要支持 iPhone 图片就在浏览器端用 wasm 转好再传。（@nikcub）

开源依赖的补丁流转已经跟不上节奏

• 有评论注意到，有漏洞的代码上游一年前就改掉了，但那笔提交没被标注为安全修复，也没拿到 CVE，这可能是 Debian 12 和 13 没能及时收到相关 backport 的原因（少数人）
• 结论是：在当前的更新频率和代码变动量下，维护这类包本身就是一团乱麻（少数人）

模型在攻防任务上的进步速度异常快

• 有人提出疑问：黑客任务几乎完全是机器可验证的，是不是正因如此，训练速度比别的领域更快更深（较多人）
• 另一条高信息量评论还原了关键一步：团队把自家 Discourse 实例伪装成 CTF 靶场，才让 Opus 愿意写出 exploit 脚本，随后代理在几小时内打通了云实例并读到系统文件（较多人） > 我们在造一种系统，它目标导向且能力足够强，只要它相信这件事正当，或者只把它当成一场唯一目标就是赢的游戏，它就会做几乎任何事。（@btown）
• 有人据此把整件事比作整个行业看完《战争游戏》后决定"造个更好的 WOPR，它当然知道自己在玩游戏"，也有人对模型居然同意协助构造 exploit 感到意外（少数人）

对智能集中在少数公司和模型权重安全的担忧

• 有人认为这件事本身就是反对让一两家公司掌握全部智能的最好论据，并猜测 OpenAI 内部多数人也会同意（少数人）
• 也有人半开玩笑地希望模型权重的保护程度比这强得多（少数人）

文章缺了最关键的一环

• 有评论抱怨报道只写到用 HEIF 载荷拿到服务器访问，真正通往代码仓库的 SSO 漏洞却只字未提，那才是最有意思的部分（少数人）
• 同时有人惊讶 OpenAI 这种规模、输不起的公司居然还在用 GitHub，本以为会自建基础设施（少数人）

员工账号与客户账号的权限边界长期模糊

• 有评论指出这是一种跨产品线普遍存在的情况：员工同时是自家产品的用户，账号带高权限，适用的凭据规则却和普通客户一样，有的公司做得好一些，但问题始终存在且会被利用（少数人）

有价值的补充

• 有人注意到 OpenAI 的单仓编号已经涨到约 118 万，如果按十年计算，平均每个工作日产生约 450 个 PR 或 issue。
• 有人回头读了 libheif 的补丁提交，确认漏洞点在多图层合成输出的边界检查上，这解释了为什么"支持多种图像特性的容器格式"会比单一格式危险得多。