一张 HEIC 图片如何打到 OpenAI 的内部仓库

一、这件事是什么

做这件事的是 Hacktron 的团队，博客署名 Harsh Jaiswal、Mohan Pedhapati、Rahul Maini 三人，研究由 Harsh Jaiswal 带头。博客发表于 2026 年 9 月 13 日，标题 Hacking OpenAI，副标题写的是“一个堆溢出加一个 SSO 配置错误，拿下 OpenAI 的内部仓库”。9 月 18 日，团队成员 s1r1us（@S1r1u5_）在 X 上发了一条十三段的串把这件事讲了一遍，截至 2026 年 9 月 19 日抓取时，首帖 230 万次浏览、1 万赞、331 条回复。

他们的起点是一个假设：OpenAI 的论坛用 Discourse 搭，登录走 auth.openai.com 的“Sign in with OpenAI”。如果论坛能被攻破，这条身份通道就有机会把权限带到 OpenAI 更核心的服务上。Discourse 本身他们过去看过，不好打，于是转向它的依赖。

目标

community.openai.com（Discourse 托管的 OpenAI 官方论坛）

入口

一张构造过的 HEIC / HEIF 图片

终点

openai/openai 内部 monorepo 的 PR #1186742

耗时

从发现到拿到仓库访问权，不到 72 小时

赏金

6,500 美元（2026-09-01 支付并标记为已解决）

二、攻击链的八环

2.1 一张表看完整条链

这是作者在 X 串第二条里给出的链条，右边一列是这页加的判断：每一环出问题的是谁。

2.2 这条链的特点：每一环单看都不致命

前四环是一个已经被上游修掉的内存漏洞，没有 CVE，没人当回事。第五环是一个配置问题。把它们接起来，一个注册论坛账号的外部人员就能读到 OpenAI 员工的工作账号。

作者在博客里特别强调过一句：能把论坛失守升级成账号接管的那个漏洞，跟 Discourse 没关系，是 OpenAI 的 SSO 问题。任何使用 OpenAI SSO 的第一方或第三方服务被攻破，都会导致同样的结果，论坛只是他们用来证明这件事的一条路。

三、第一个洞：libheif 堆溢出

3.1 一张 HEIC 为什么能碰到解码器

7 月 23 日，他们开始看 Discourse 的图片上传流程，发现 HEIC 和 HEIF 文件走的路跟别的图片不一样。Discourse 平时用 FastImage 做图片检查，但 FastImage 不支持 HEIF，所以这类文件被直接交给 ImageMagick 的 magick 命令去转换。这一步把底层的 libheif 解析器直接暴露给了用户上传的文件。

HEIC 是 iPhone 默认的照片格式。一个论坛要支持用户从手机传图，几乎一定要处理它。这个功能本身是对的，代价是多引入了一整套解析 ISO 基础媒体文件格式的代码。

3.2 补丁在上游，但没人知道它是安全补丁

他们开了一个 Opus 4.8 的会话，把 Discourse 的 Docker 镜像给它，让它检查里面装的 libheif 包有没有安全问题。跑了一段时间后，模型找到：上游的一些安全修复没有被回补到这个包里。缺的这块会导致 HEIC 解码过程中出现堆缓冲区溢出，进而拿到越界读写的能力。

漏洞代码在上游前一年就被改过，提交信息写的是 simplify overlay overlap area computation（简化覆盖层重叠区域的计算），没有标成安全修复，也没有申请 CVE。³ 下游因此没有理由去回补它。Debian 12 和 13 都漏掉了，Discourse 的 Docker 镜像基于 Debian 12，装的是有问题的 libheif 1.19.7；当时 Debian 13 里也还是有问题的 1.19.8。Debian 直到 2026 年 8 月 8 日才发出针对 Debian 13 的安全更新。⁴

3.3 从越界读写到执行命令

7 月 24 日，他们用 Opus 4.8 做出了一个可用的 ImageMagick / libheif 代码执行利用，条件是关掉 ASLR（地址随机化）。接着开了几个会话想让它在 Discourse 的默认配置下、也就是开着 ASLR 的情况下稳定工作，没成功。

当天傍晚 Anthropic 发布了 Claude Opus 5。他们新开一个会话，三小时内拿到了一个能在本地 Mac（ARM64）上工作的利用，然后让它移植到 Discourse 用的 x86-64 环境和 jemalloc 内存分配器配置上。7 月 25 日早上 6 点，通过图片上传的本地远程代码执行确认可用。

四、第二个洞：OpenAI 的单点登录

4.1 论坛的控制权怎么换成别人的身份

拿到论坛的代码执行和管理员权限之后，第二个漏洞才是真正值钱的那个。作者在 X 串里的原话是：“第二个 bug 更严重：一个 OpenAI SSO 漏洞。利用这个缺陷，我们把论坛的利用变成了对在该论坛登录过的人的 ChatGPT 和 Codex 账号的访问权，其中包括 OpenAI 员工。”

关键词是“无需交互”。博客里写的是 no interaction account takeover：论坛的活跃成员不需要点任何链接、不需要再次登录，账号就可以被接管。受影响的不只是 OpenAI 员工，还包括一些跟 OpenAI 无关的普通用户。

4.2 爆炸半径在连接器上

ChatGPT 和 Codex 可以连接外部服务。作者列出的有 Outlook、Gmail、Google Drive、Slack、GitHub。一个被接管的账号，能触达的东西远超对话记录本身。

他们实际用到的那个 OpenAI 员工账号，Codex 连着 OpenAI 的 GitHub 组织。

4.3 公开信息里还缺什么

五、怎么证明的：一个无害的 PR

确认了假设之后，他们先把报告发给 OpenAI，然后接管了一个 Codex 连着 OpenAI GitHub 组织的员工账号。为了证明权限是真的、同时不去读任何内部代码，他们给这个账号的 Codex 发了一条指令，让它在 OpenAI 的内部 monorepo openai/openai 里开了一个 PR，编号 #1186742。博客里贴了这个 PR 的截图，链接应 OpenAI 要求删去。做完这一步，他们停止了所有进一步测试，时间是 7 月 25 日 15:30 UTC 左右。

这个动作值得单独看一眼：他们让目标账号自己做了一件可审计、可撤销、不泄露内容的事，用它来证明访问权。开 PR 留下记录，读代码不留。

六、AI 在这次里干了多少活

6.1 Opus 4.8 卡住，Opus 5 当天做出来

这是整篇博客里最值得记住的一组对比。同一个问题，Opus 4.8 用好几个会话都没能在开启 ASLR 的情况下做出稳定利用；Opus 5 发布几小时后，他们把同一个问题交给它，成功了。

博客里还提到第二次落差：在后续针对其他公司的研究里，从 Opus 5 到 GPT-5.6 Sol 又有一次明显的跳跃，判断标准是“除了知道目标有漏洞之外，对目标系统一无所知”时能不能打下来。

每个目标的测试都从上传一张图片开始。之后要把内存破坏变成可靠的内存泄露或者一个 shell，通常不知道对方的 libheif 版本、libc 版本和部署环境。模型几乎是盲打，一到两天内为每家公司调整出可用的利用。作者的说法是，这不算完全自主的攻击，熟练的人工引导仍然重要，但一个小团队能完成的工作量提高了很多。代码执行落到沙箱或受限环境里时，模型还参与了提权、横向移动和绕过已有防护。

6.2 把自己的靶机包装成 CTF

本地跑通之后，他们把 Claude 放进一个自主的 /goal 循环里，目标是自己的 Discourse Cloud 实例。因为 Opus 拒绝为远程实例编写利用代码，他们把目标通过 rce.ee/ctf-forum 做了代理，让它看起来像一个 CTF 靶场。

早上 10 点他们再看的时候，这个 agent 已经在 Discourse Cloud 上拿到了代码执行，并且读出 /etc/hosts 作为证明。用它生成的利用脚本，他们拿下了 OpenAI 的实例。

6.3 花了多少钱

OpenAI 这一次，agent 用了几天，人工只花了几个小时。后续那个扩展到 Slack、Meta 等公司的研究项目，规模是这样：

作者在结尾写的那段判断可以直接抄下来：软件长期以来受益于一种“靠复杂度获得的安全”。代码和漏洞本身可以是公开的，但把一个 bug 变成可靠的利用，仍然需要稀缺的专业能力、大量时间和对目标环境的了解。已知的内存破坏漏洞操作成本很高，0day 基本只留给最高价值的目标。这从来不是一道真正的安全边界，但它在实践中保护了普通公司。AI 正在把这层保护拿掉，方法是把稀缺的专业能力变成算力。过去需要一支资源充足的团队干几个月的活，现在可以压缩到几天。

6.4 几乎没人发现

作者写道，在整个研究过程里，除了 Shopify，他们不知道有任何公司检测到了这些活动——即使已经发出去几千张图片、对方的图片处理程序反复崩溃。

七、完整时间线

时间来自博客的披露时间线一节，UTC。

1. 07-23
   开始审查 Discourse 的图片上传流程，发现 HEIC / HEIF 走 ImageMagick。
2. 07-24
   用 Opus 4.8 做出关闭 ASLR 条件下的利用。当晚 Claude Opus 5 发布，新会话三小时内产出 ARM64 版本。
3. 07-25 05:00
   确认拿到代码执行（05:00 到 06:00）。团队在 community.openai.com 的 Discourse 环境上获得远程代码执行和管理员权限。
4. 07-25 08:00
   提交 Bugcrowd（08:00 到 10:00）。确认跨产品影响后，团队内部先商量好披露流程，再通过 OpenAI 的赏金计划提交报告。
5. 07-25 13:30
   接管员工账号并做证明（13:30 到 15:30）。在内部 monorepo 创建无害 PR，更新 Bugcrowd 报告，同时在 X 上联系 OpenAI 的朋友直接通知，15:30 左右停止一切测试。
6. 07-25 22:49
   OpenAI 侧确认已修复，距首次提交约 14 小时。
7. 07-25
   另行向 Discourse 的 HackerOne 项目提交报告（周六）。
8. 07-26
   Discourse 回复（周日）。
9. 07-27
   Discourse 修复就绪（周一），并加入图片处理沙箱作为纵深防御。
10. 07-28
    Discourse 发布公告 GHSA-vhm9-85gw-x335，附补丁和重建指引。⁵
11. 08-08
    Debian 发布针对 Debian 13 的 libheif 安全更新 DSA-6417-1。⁴
12. 09-01
    OpenAI 支付 6,500 美元赏金并标记为已解决。
13. 09-13
    Hacktron 发表博客 Hacking OpenAI。
14. 09-18
    s1r1us 在 X 上发布十三段的说明串；同日 Harsh Jaiswal 公布更大范围的 libheif 研究。

八、争议：6,500 美元

赏金金额是 X 串下面讨论最多的一条。那条讲报告和修复的帖子有 68 条回复，是整串里回复最多的。Nik Cubrilovic（@dir）的回复只有一行：

> to which OpenAI paid a $6,500 bounty

yikes ..

来源：X 回复，2026-09-18

OpenAI 在博客的时间线里留了一条说明，解释这个金额的范围：

为明确该奖励的范围：针对 Discourse 托管的 community.openai.com 的测试被明确排除在我们的赏金计划之外。该奖励认可的是 OpenAI 侧的发现，而不是针对 Discourse 的行为。

来源：hacktron.ai 博客时间线，OpenAI 评论

这条说明本身是这次事件的一个教训：赏金范围按资产划线，而攻击者按身份链条走。论坛不在范围内，但 SSO 让论坛成了核心系统的入口。

九、可以抄走的防守清单

9.1 你自建了 Discourse

博客开头给了一个警告框，照抄如下：如果你自建 Discourse，现在就重建你的安装。旧的 Docker 镜像里可能带着有问题的 libheif 依赖，允许通过图片上传执行代码。在 /var/discourse 下执行：

cd /var/discourse
git pull
./launcher rebuild app

只在网页后台点更新，可能不会替换底层镜像。Discourse 托管的客户已经打过补丁。

9.2 你的产品收用户上传的图片

判断标准很简单：如果你的程序处理用户可控的图片，并且接受 .heic / .heif / .avif，那它很可能受影响。

• 升级上游。通过发行版的安全渠道或上游发布，装上最新的带安全补丁的 libheif 和 libde265。截至 2026 年 9 月 14 日，上游最新的 libheif 安全版本是 v1.23.4；v1.23.2 已被后续的安全修复取代。⁷
• 别只看版本号。发行版可能在一个较老的上游版本号下带了回补，要去看这个包的安全公告，而不是比较版本数字。
• 这不是单一版本的问题。受影响的是一整个版本族系，1.19.x、1.20.x、1.22.x、1.23.x 都有；任何没打上最新上游安全补丁的部署都可能有问题。
• 纵深防御。ISO 基础媒体文件格式本身复杂，解码器还在持续更新，以后还会出内存安全问题。用不到就在生产环境关掉对不可信 HEIF / AVIF 的解码；用得到就把图片处理放进加固过的一次性沙箱。ImageMagick 的安全策略支持限制允许的格式和资源占用。⁸

9.3 你在做单点登录

把“某个用了我们 SSO 的站点被攻破”当成迟早会发生的事，然后问：它能换到多少身份？这次的区别不在论坛有多重要，而在论坛的控制权可以兑换成 ChatGPT 账号。

具体到可以检查的地方：第三方站点（论坛、状态页、社区、文档站）用不用同一套身份；这些站点拿到的令牌作用域有多大；一个站点被攻破后，有没有办法只吊销它而不影响其他。

9.4 你接了 AI 连接器

一个 ChatGPT 或 Codex 账号连着 GitHub、Slack、邮箱、云盘，被接管一次就等于这几样一起丢。给连接器的权限按最小范围配，写操作留审计记录，定期看一遍哪些账号连了什么。

这一条对个人同样成立：你自己的 AI 账号连了几个服务，就是几个服务共用一把钥匙。

9.5 你负责监测

几千张图片进来、图片处理程序反复崩溃，只有一家公司察觉。把解码进程的崩溃率做成告警，是这次事件里成本最低的一条防线。

十、作者 X 串全文

s1r1us（@S1r1u5_）2026 年 9 月 18 日 10:43 发布，共十三条。下面是中文整理，每条附英文原文。

1. 7 月 25 日，我们黑掉了 OpenAI。两个漏洞让我们接管了 OpenAI 员工（以及一些无关用户）的 ChatGPT / Codex 账号，并触达了连接的服务：Outlook、Slack、GitHub 等。我们用 OpenAI 内部代码库里的一个 PR 证明了这一点。全程不到 72 小时。
   英文原文

   On July 25, we hacked OpenAI. Two bugs let us take over ChatGPT/Codex accounts of OpenAI employees (+some unaffiliated users) and reach connected services: Outlook, Slack, GitHub, etc. We proved it with a PR in OpenAI's internal codebase. It took us <72h.

2. 整条利用链大致是：1. HEIC / HEIF 上传；2. ImageMagick 解码；3. libheif 堆溢出；4. community.openai.com 上的 RCE；5. 严重的 OpenAI SSO 缺陷；6. ChatGPT / Codex 接管；7. 连接的 GitHub 访问权；8. 内部仓库 PR #1186742。
   英文原文

   At a high level, this was the full exploit chain. 1. HEIC/HEIF upload 2. ImageMagick decoding 3. Heap overflow on libheif 4. RCE on community.openai.com 5. Critical OpenAI SSO flaw 6. ChatGPT/Codex takeover 7. Connected GitHub access 8. Internal repo PR #1186742

3. 图片处理包 libheif 有一个已知漏洞，上游已修复，但那次修复从未被标记为与安全相关，在 Discourse 里仍然存在。上传一个 HEIF 文件就让我们拿到了 OpenAI 论坛 community.openai.com 的代码执行。
   英文原文

   The image package libheif had a known vulnerability, fixed upstream, but the fix never flagged as security-relevant and was still present in Discourse. Uploading a HEIF file gave us RCE on the OpenAI forum community.openai.com.

4. 第二个 bug 更严重：一个 OpenAI SSO 漏洞。利用这个缺陷，我们把论坛的利用变成了对在该论坛登录过的人的 ChatGPT 和 Codex 账号的访问权，其中包括 OpenAI 员工。
   英文原文

   The second bug is more serious: an OpenAI SSO vulnerability. Using this flaw, we turned our Discourse forum exploit into access to ChatGPT and Codex accounts belonging to people who had signed into it, including OpenAI employees.

5. 这些账号可以（其中一些确实）通过 Codex 或 ChatGPT 连接到 Outlook、Gmail、Google Drive、Slack、GitHub 等服务。这让潜在影响远大于 ChatGPT 本身。
   英文原文

   Those accounts could be (and some were) connected to Outlook, Gmail, Google Drive, Slack, GitHub, and other services via Codex or ChatGPT. This made the potential impact much larger than ChatGPT alone.

6. 为了在展示影响的同时把暴露降到最低，我们使用了一个连着 OpenAI GitHub 组织的受影响员工账号。Codex 在他们的内部 monorepo 里创建了一个无害的 PR，我们没有读取任何敏感代码。这向我们证明了访问权是真实的。
   英文原文

   To demonstrate impact while minimising exposure, we used one affected employee account connected to OpenAI's GitHub org. Codex created a harmless PR in their internal monorepo without us reading sensitive code. That proved to us that the access was real.

7. 我们把这个 bug 报告给了 Discourse 和 OpenAI。OpenAI 在我们首次提交后约 14 小时修复了 SSO 问题。Discourse 周六收到我们另一份报告，周日回复，周一修复完成。OpenAI 给了我们 6,500 美元。
   英文原文

   We reported the bug to Discourse and OpenAI. OpenAI fixed the SSO issue roughly 14 hours after our initial submission. Discourse received our separate report Saturday, replied Sunday, and had a fix Monday. OpenAI awarded us $6,500.

8. AI agent 完成了其中相当一部分利用开发工作。Opus 4.8 找到了 libheif 漏洞并构建了部分利用。Opus 5 发布几小时后，它把利用适配到了 Discourse，并在我们的测试实例上拿到了 RCE。
   英文原文

   AI agents did a meaningful share of the exploit work. Opus 4.8 found the libheif vulnerability and built a partial exploit. Hours after Opus 5 launched, it adapted the exploit to Discourse and achieved RCE on our test instance.

9. 我们从黑 OpenAI 中得到的主要结论：AI 正在降低开发利用所需的稀缺专业能力。过去要花几个月的工作，现在几天就能做完。即使是领先的 AI 实验室也可能存在漏洞。防守方需要修架构、更快地打补丁，并限制连接物件的影响范围。
   英文原文

   Our main takeaway from hacking OpenAI: AI is reducing the amount of scarce expertise needed to develop exploits. Work that once took months can now take days. Even leading AI labs can be vulnerable. Defenders need to fix the architecture, patch faster, and limit the blast radius of connected things.

10. 这项工作由我们的团队 @HacktronAI 完成，@rootxharsh 带队，还有我和 @iamnoooob。完整的利用链细节以及我们如何发现它，都发在博客上。
    英文原文

    This work was done by our team @HacktronAI led by @rootxharsh along with me and @iamnoooob. We have published the full details of the exploit chain, as well as how we discovered it, on our blog here.

11. 另外我们不是什么随便的人，可以看看我们以前的工作，我们跟 Perplexity、Vercel 这样的公司合作。
    英文原文

    also we are not some random dudes, check our work before, we work with companies like perplexity and vercel.

12. 可以看 @LiveOverflow 的视频《How OpenAI got hacked with an image》。
    英文原文

    Check out @LiveOverflow video: How OpenAI got hacked with an image. Two guys hacked OpenAI with a malicious HEIF image.

13. 黑掉 OpenAI 之后，我们开始看其他受同一个图片解析器影响的公司，这个 bug 影响了大量公司，包括 Slack、GitHub Enterprise、Meta 等。（引用了 @rootxharsh 同日发布的 HEIF Heist 串：一项持续数月的 libheif 调查，让他们得以攻破 OpenAI、Slack、Meta、GitHub Enterprise、Rails、Next.js、ImageMagick 等等。）
    英文原文

    After we hacked openai, we started looking into other companies that was affected by same image parser, the bug affects numerous companies including slack, github ent, meta etc.

博客里也提到了这项更大范围的研究：他们把调查扩展成 HEIF Heist，追踪 libheif 在 Slack、Meta、GitHub Enterprise、Ruby on Rails，以及 Next.js、Astro、Gatsby 这些 Node.js 框架里的踪迹。博客引用了 xkcd #2347¹：一个数量惊人的常用软件，底下压着同一个不起眼的图片库。各家公司的技术细节会在接下来几周陆续公布。

十一、方法与来源

这页的内容全部来自两个指定来源：hacktron.ai 的博客文章和 @S1r1u5_ 的 X 串。博客正文用 curl 抓取后去标签取纯文本；X 串用浏览器打开原帖，展开两条被折叠的帖子后读取页面文本。抓取日 2026 年 9 月 19 日。

没有拿到的部分：博客里的两张配图（xkcd 2347 的插图、内部 PR 的打码截图）未内嵌；X 串的浏览量、点赞等数字是抓取当时的值，会继续变化；SSO 漏洞的技术细节两个来源都没写（见 4.3）；作者提到的 HEIF Heist 专题站和 LiveOverflow 的视频不在本次范围内，只在下面列出链接。

责任归属那一列（2.1 表格最右列）是根据两个来源的描述做的整理判断，不是原文的分类。

1. Hacktron AI（Harsh Jaiswal、Mohan Pedhapati、Rahul Maini），《Hacking OpenAI》，2026-09-13，hacktron.ai/blog/hacking-openai
2. s1r1us（@S1r1u5_），X 串，2026-09-18，x.com/S1r1u5_/status/2100777801335095383
3. xkcd #2347 Dependency，xkcd.com/2347
4. Discourse Meta，《Support for HEIC images》，meta.discourse.org/t/support-for-heic-images/144326
5. libheif 提交 simplify overlay overlap area computation，github.com/strukturag/libheif
6. Debian 安全公告 DSA-6417-1：libheif 安全更新，2026-08-08，lists.debian.org
7. Discourse 安全公告 GHSA-vhm9-85gw-x335，2026-07-28，github.com/discourse/discourse/security/advisories
8. Anthropic，《Introducing Claude Opus 5》，anthropic.com/news/claude-opus-5
9. libheif v1.23.4 安全维护版本，github.com/strukturag/libheif/releases/tag/v1.23.4
10. ImageMagick 安全策略，imagemagick.org/security-policy
11. RAND，《A Playbook for Securing AI Model Weights》，博客结尾引用，rand.org
12. HEIF Heist 专题站（本次未抓取），heif-heist.com