研究人员利用 Claude 在漏洞赏金链中入侵 OpenAI 内部系统

2026年7月25日，安全公司 Hacktron AI 的一个三人团队使用 Anthropic 的 Claude Opus 5，将两个漏洞串联起来，接管了属于 OpenAI 员工的 ChatGPT 和 Codex 账户，随后利用其中一个账户在 OpenAI 的内部源代码仓库中发起了一个拉取请求。入口不是登录页面或 API 密钥，而是 OpenAI 公共帮助论坛 community.openai.com 上的一个图片上传功能，该论坛运行在开源论坛软件 Discourse 上。第二个漏洞位于 OpenAI 自己的共享登录系统中，而不是论坛中。没有读取任何源代码，没有合并任何内容，没有触及任何客户数据，档案也没有记录任何现实世界中的危害——这是向供应商报告的安全研究，而不是对其发动的攻击。该记录日期为 2026 年 9 月 18 日，即 TechCrunch 报道该发现的当天。这起事件与Orca AI Incident Archive中其他有记录的条目并列，其中每条记录都带有各自的来源、严重性、置信等级和争议标记。

有两件事使这起事件不止是一个花哨的漏洞赏金故事。首先是速度：Hacktron 表示，从首次查看该论坛到持有内部代码仓库访问权限，整个路径耗时不到 72 小时，而且它最初使用的模型无法完成这项工作。其次是醒目标题数字所掩盖的一处矛盾——报道中提到的 CVE，即 CVE-2026-32882，被记录为一次会导致软件崩溃或内存泄漏的越界读取，而不是代码执行漏洞。Discourse 自己的安全公告将该结果评定为远程代码执行。两者都是真的，而它们之间的差距正是 AI 的贡献实际所在。

Hacktron 声称发现了什么，以及何时发现的

Hacktron 于 2026 年 9 月 13 日在其自己的网站上发布了题为“Hacking OpenAI”的文章。据 TechCrunch 报道，The Wall Street Journal 于 9 月 17 日星期四晚上报道了此事，TechCrunch 则于 9 月 18 日星期五跟进。文中描述的事件发生在大约八周前，而 Hacktron 自己的时间线对它们的记录很精确：

• 2026年7月23日 — 团队沿着 Discourse 的 HEIF 上传路径，经 ImageMagick 追踪至 libheif，并发现了该堆溢出漏洞。

• 2026年7月24日 — Claude Opus 4.8 在关闭 ASLR（标准的地址随机化防御机制）的情况下，生成了一个可用的代码执行漏洞利用程序。

• 2026年7月25日 06:00 UTC — 团队使用较新的模型确认，在开启 ASLR 的情况下，通过图片上传可以实现可靠的本地代码执行。

• 2026年7月25日，08:00–10:00 UTC — 团队通过 OpenAI 在 Bugcrowd 上的漏洞赏金计划提交了一份报告。

• 2026年7月25日，10:00 UTC — 该漏洞先在该团队自己的 Discourse Cloud 实例上成功利用，随后又在 OpenAI 的论坛上成功利用。

• 2026年7月25日，13:30–15:30 UTC — 团队使用一名 OpenAI 员工的 Codex 账户，在 OpenAI 的内部 monorepo 中发起一个无害的拉取请求，随后停止测试。

• 2026年7月25日 22:49:45 UTC — OpenAI 回复确认该问题已修复，此时距最初提交约 14 小时。

• 2026年7月28日 — Discourse 发布安全公告 GHSA-vhm9-85gw-x335，并提供补丁和重建指南。

• 2026年9月1日 — OpenAI 支付 6,500 美元赏金，并将该报告标记为已解决。

上面的日期是 Hacktron 自己给出的，并非重新推算。它自己那篇帖子上的 9 月 13 日发布日期、9 月 17 日的 Wall Street Journal 报道以及 9 月 18 日的 TechCrunch 报道，属于另一段更晚的时间线：实际工作是在 7 月完成的，文章则到 9 月中旬才发出。

一次图片上传如何演变成服务器被攻陷

这条链条始于一个平平无奇的功能。Discourse 通常用一个名为 FastImage 的库检查上传的图片，但 FastImage 并不支持 HEIF——也就是苹果设备用于照片的容器格式。因此，这些文件会被交给 ImageMagick 的命令行工具进行转换，而该工具又把它们交给 libheif 来解码。这就把一个解析器直接摆在了攻击者可控的文件面前——正是 xkcd 那则依赖关系漫画所设想的模式，Hacktron 也在其参考中引用了它。

Hacktron 发现 Discourse 的 Docker 镜像中安装的 libheif 包缺少安全修复。Discourse 的镜像基于 Debian 12 构建，安装的是 libheif 1.19.7；当时 Debian 13 仍提供 1.19.8。该漏洞本身位于 HeifPixelImage::overlay() 中，该函数会将叠加图像合成到基础图像上。根据 libheif 自己的安全公告，当叠加子图像的 alpha 通道与颜色通道具有不同的位深时，该函数会使用颜色通道的步幅而不是 alpha 平面的步幅来索引 alpha 平面。对于一幅 100×50、10 位颜色和 8 位 alpha 的图像，公告计算出该代码会读取超出 7,168 字节缓冲区末尾的 3,123 字节。

这会让攻击者获得泄露的堆内存，这对于攻破地址随机化很有用——但其本身并不能带来 shell。从泄露到执行，正是需要模型参与的部分，也是 CVE 未描述的部分。随后这条攻击链跨越了一个 Hacktron 认为才是真正关键的信任边界：OpenAI 的论坛通过 auth.openai.com 提供“Sign in with OpenAI”，这与员工在其他地方使用的是同一套单点登录。控制论坛服务器意味着研究人员可以接管在 OpenAI 工作的论坛成员的 ChatGPT 和 Codex 账户，而无需受害者进行任何交互。正如 Hacktron 所说，“用于提权的漏洞并非 Discourse 特有”，任何使用该单点登录的 OpenAI 第一方或第三方服务都会授予同样的访问权限。

已确立的，以及推断出的

档案将这条记录评为置信度A、无争议、严重性高，且未记录到实际伤害。这些字段经得起推敲。但相关报道仅出自单一研究团队的说法，属于得到佐证而非独立重建，值得将有据可查的内容与所断言的内容区分开来。

由原始记录确认。 CVE-2026-32882 存在，于 2026 年 5 月 19 日发布，影响 libheif 1.21.2 及更早版本，并在 libheif 1.22.0 中修复。MITRE 记录将其评为 7.1 分，攻击向量为网络，复杂度低，所需权限为无，需要用户交互，影响为低机密性和高可用性——即崩溃或内存泄漏。Discourse 的公告 GHSA-vhm9-85gw-x335 于 2026 年 7 月 28 日发布，并致谢 hacktronai-research，跟踪同一 CVE，并将结果评级为高，分值为 8.8，所需权限低，无需用户交互，且对机密性、完整性和可用性三者均有高影响。它列出了已修补版本 2026.7.0、2026.6.1、2026.5.2 和 2026.1.6，并指出最新的 Docker 镜像包含已修补的 libheif。

由两家独立媒体证实。 研究人员使用 Claude 发现并将该链条武器化、一次论坛被攻破导致员工账户被访问、OpenAI 在大约 14 小时内修复并支付了 6,500 美元、访问证明只是一个拉取请求，以及 OpenAI 表示测试论坛本身不在其漏洞赏金范围内——所有这些都出现在 The Hacker News 和 TechCrunch 的报道中，二者都直接引用了 Hacktron 的详细报告。

Hacktron 声称，未经独立验证。论坛上的代码执行究竟是否确实以所述方式实现——即通过自主代理循环和代理测试实例——仅依据 Hacktron 的说法，尚未被第三方复现；The Hacker News 表示，它已联系 Hacktron，询问论坛代码执行是如何实现的以及账户访问的范围，但未报告收到答复。关于同一类缺陷波及 Slack、Meta、GitHub Enterprise 和 Web 框架的说法，按 The Hacker News 自己的评估，“证据支持并不均衡”：Vercel 的公告确认了一个 Next.js 缺陷，libheif 的维护者确认了与 Meta 相关的该漏洞存在可用利用程序，但关于在许多应用中实现代码执行的更广泛说法尚未得到独立确认。OpenAI 完全没有发布关于该登录缺陷的技术说明；它是通过修复和付款来证实这一发现，而非通过记录这些账户接管事件。

完全未得到确认。有多少员工账户可被访问到——The Hacker News 称“数个”，TechCrunch 称“多个”，而 Hacktron 未给出数字。该漏洞是否曾被任何其他人利用：The Hacker News 报道没有现实世界使用的迹象，并指出截至 2026 年 9 月中旬，该 CVE 不在美国政府已知被利用漏洞清单上，同时警告该清单并不能证明任何一方。以及已经打好补丁的组织是否仍应追查更早的访问痕迹——The Hacker News 称消息源对此保持沉默。

模型做了什么，以及人类做了什么

能力跃升是Hacktron自身强调的部分，而且是以其自己的话记录的，而不是推断出来的。团队首先使用了Claude Opus 4.8——在一个提供给网络安全研究人员的构建版本中——来检查已安装的libheif包，并在禁用ASLR的情况下构建漏洞利用程序。开启ASLR后，它在多个会话中停滞不前。Anthropic于2026年7月24日晚发布了Claude Opus 5；在一个全新的会话中，新模型在大约三小时内为本地Mac生成了可用的ARM64漏洞利用程序，到第二天早上06:00时，已被移植到Discourse使用的x86-64配置上。

Claude Opus 5 在发布时同样内置了防护措施，以防编写针对真实目标的漏洞利用代码。Hacktron 表示，他们通过让模型指向其自有的 Discourse Cloud 实例——经由名为 rce.ee/ctf-forum 的主机进行代理，使目标看起来像一场夺旗演练——并让它以自主目标循环的方式运行，从而绕过了这些防护。该团队明确表示，这并非无人值守的黑客攻击：“熟练的人工指导仍然至关重要，”文中写道，而小团队所能完成的工作量却大幅增加。在规模更大的 HEIF Heist 行动中，Hacktron 表示，对于事先对目标一无所知的情况，他们使用了 OpenAI 的 GPT-5.6 Sol。

经济账才是 Hacktron 想让读者领会的论点。在更广泛的行动中——沿着同一类缺陷追踪 Slack、Meta、GitHub Enterprise、Ruby on Rails 以及 Next.js、Astro 和 Gatsby 框架——它表示，三名研究人员两个月的工作在 token 上花费不到 3,000 美元，而每适配一个新目标只需一两天。它还表示，除 Shopify 外，它不知道有任何公司检测到该活动，尽管发送了数千张测试图像，且图像处理器反复崩溃。

后来发生了什么变化？

Discourse 于周六收到报告，周日回复，周一前完成修复，并于 7 月 28 日发布安全公告，同时增加了图像处理沙箱作为纵深防御。其公告警告自托管者，仅更新 Web 界面可能无法替换底层库，必须从 /var/discourse 进行完整重建。Debian 于 2026 年 8 月 8 日发布了针对 Debian 13 的 libheif 的安全更新，编号为 DSA-6417-1。在上游方面，Hacktron 提醒读者，截至 2026 年 9 月 14 日，libheif 1.23.4 是最新的安全版本，并指出发行版软件包可能在较旧的版本号下包含向后移植的修复，因此除了上游版本外，还必须检查软件包公告。

对 OpenAI 而言，修复在 7 月 25 日报告后约 14 小时内上线，赏金于 9 月 1 日支付。该公司在付款时附上了范围澄清：针对 Discourse 托管的 community.openai.com 进行测试已被明确排除在其漏洞赏金计划之外，而且这笔奖励认可的是 OpenAI 一侧的发现，而非针对 Discourse 采取的行动。这一点值得仔细留意。这 6,500 美元是就登录（sign-on）漏洞发现支付的，而不是为论坛攻击链支付的；而按 OpenAI 自己的说法，使该攻击链成为可能的论坛相关工作属于范围之外。

为什么 CVE 与标题不一致

对这一案例的报道往往把两种不同的严重性评级压缩成一个。libheif 公告和 CVE 描述的是一次越界读取，其机密性影响评级为低、可用性影响评级为高：崩溃，或内存泄露。Discourse 公告描述的是当这次读取与漏洞利用工作以及第二个缺陷结合时发生了什么，并给出 8.8 分，且在全部三个类别上均为完整影响。两者都没有错；它们回答的是不同的问题。CVE 回答的是“这个库缺陷有多严重？”，而论坛公告回答的是“这个论坛问题有多严重？”

实际后果是，读者在 CVE 信息源中扫描 libheif 的严重远程代码执行漏洞时，不会在这里找到相关条目，并可能合理地认为自己不受影响。Hacktron 自己的指导则相反：任何接受用户提供的 HEIC、HEIF 或 AVIF 图像并通过未修补的 libheif 解码这些图像的服务，都应被视为已暴露；仅凭版本号并不足以作为检查依据，因为向后移植的补丁会在过时的版本字符串下变化。它建议的三项缓解措施是：通过发行版的安全渠道或当前上游版本更新 libheif 和 libde265；在不需要的地方禁用对不可信 HEIF 和 AVIF 的解码，或将图像处理隔离在临时沙盒中；以及——这一项具有超越图像库的普遍意义——限制单点登录所信任的服务范围，并在敏感操作前要求重新进行身份检查，而不是信任现有会话。

最后一点才是具有可迁移性的发现。论坛本身并不是漏洞；它是入口。一个公开、信任度较低的服务与内部工具共用同一个身份提供商，意味着只要攻破整个环境中防护最薄弱的环节，就能获得最高权限。Hacktron 的叙述中没有任何内容表明 OpenAI 对论坛本身疏忽大意——按该团队自己的评估，Discourse“实际上并不是一个容易攻击的目标”——而这正是该案例被援引的原因：出问题的是信任边界，而不是漏洞。