Claude 未能攻破 OpenAI，随后 Anthropic 推出了 Opus 5

Hacktron AI 的三名安全研究人员在一个被广泛使用的图像库中发现了内存破坏漏洞。发现漏洞反而是容易的部分。

困难之处在于将其变成能在真实服务器上运行的攻击手段。因此，7 月 24 日，他们把这项工作交给了 Anthropic 的 Claude Opus 4.8。该模型只有在关闭操作系统内存随机化保护的情况下才能成功；而当这项保护开启时——这正是所有生产环境服务器的运行方式——它编写的任何内容都无法奏效。

当晚，Anthropic 发布了 Opus 5。

第二天早晨，研究人员带着同一个漏洞和新模型再次尝试。大约三小时后，Opus 5 已经构建出可在他们桌上一台 Mac 上运行的 ARM64 漏洞利用程序。又过了约四小时，他们便在一个测试论坛上实现了远程代码执行。

在项目开始后不到 72 小时，他们已经能够读取 OpenAI 的私有 monorepo——方法是使用一名 OpenAI 员工的 Codex 账户，对 README 发起拉取请求，随后就此停止。

Hacktron AI 本周在其网站上发布了这起事件的详细经过。

一切始于一张图片

漏洞并不在 OpenAI 自己编写的代码中。Hacktron 测试的是公司的用户论坛 community.openai.com，该论坛运行在 Discourse 上——这是数千个网站都在使用的现成论坛软件。

Discourse 通常使用 FastImage 检查上传的图片。但 FastImage 无法处理 HEIC 和 HEIF 文件，因此这些文件会被转交给 ImageMagick，而 ImageMagick 则使用 libheif 对其进行解码。该论坛所用 Debian 12 基础镜像中运行的 1.19.7 版本存在一个堆缓冲区溢出漏洞，特制文件可以触发该漏洞。

上游项目在前一年已经合入修复。但该提交没有被标注为安全修复，也从未获得 CVE 编号，因此没有触发向该论坛所使用 Debian 软件包的回移——一个已经修复的漏洞，因无人标注而始终仍可被利用。

研究人员针对 Discourse 所运行的 x86-64 和 jemalloc 配置调整了漏洞利用代码，一张畸形的 HEIC 图片便足以触发远程代码执行。

Discourse 后来在安全公告 GHSA-vhm9-85gw-x335 中确认了该漏洞，将上游 libheif 漏洞——编号为 CVE-2026-32882——按 CVSS 严重性量表评为 8.8 分（满分 10 分）。The New Stack 已联系 Hacktron AI，以获取研究人员使用 Claude 的更多细节；如收到回复，本文将进行更新。

一个漏洞利用，更长的攻击路径

论坛上的代码执行对论坛而言当然是_糟糕的一天_。但它本不该成为该论坛所属公司的糟糕一天。攻击链从这里进入了 OpenAI 自身的系统。随后，Hacktron 发现了 OpenAI 单点登录系统中的一个缺陷：为论坛签发的登录令牌携带过多权限，可向关联的 ChatGPT 和 Codex 账户授予完整 API 访问权。其中一些账户属于 OpenAI 员工。

一名员工的 Codex 账户连接至 OpenAI 的 GitHub 环境，由此打开了访问公司私有代码库的路径。Hacktron 表示，其他账户还可能暴露包括 Slack 和电子邮件在内的已连接服务。

团队到此为止。他们使用 Codex 针对 OpenAI 私有的 openai/openai monorepo 进行了一项无害的文档修改，并发起拉取请求——这足以证明访问权限真实存在，没有做更多操作。Hacktron 的报告称，该拉取请求的详细信息应 OpenAI 要求已被删节。

从助手到漏洞利用开发者

截至此时，这三名经验丰富的研究人员仍参与在流程中。因此，Hacktron 再次进行了实验，且大部分时间不再让人类介入。

他们将 Claude 放入一个自主 Agent 循环中——给它一个目标、一个攻击对象，以及持续工作的时间——并将目标指向他们自己部署的一个 Discourse 实例。模型自行完成了攻击，实现远程代码执行，并通过从容器内部读取 /etc/hosts 证明了这一点。

让它开始工作只需一个误导手段：Opus 拒绝编写针对在线远程主机的漏洞利用程序。因此，团队通过 rce.ee/ctf-forum 代理了他们自己的实例，这个 URL 让目标看起来像是夺旗赛（CTF）练习的一部分。

内存破坏漏洞利用始终是专家级工作，涉及内存布局、内存分配器、操作系统内部机制及各种保护措施，而这些因素令一切变得极不可靠。Hacktron 的这次实验表明，这类工作中相当一部分现在或许可以委托给 AI 完成。它也表明，至少从模型的角度看，安全研究与攻击开发之间的界线，在一定程度上取决于你将目标视为什么。

完整攻击链

综合起来，攻击过程如下：

HEIF 上传 → libheif 溢出 → 论坛上的代码执行 → 权限过大的 SSO 令牌 → 员工 ChatGPT/Codex 账户 → 已连接的 GitHub → 在 openai/openai 中发起拉取请求

两个月项目，成本不足 3,000 美元

这次对 OpenAI 的入侵，是团队称为“HEIF Heist”的更大项目中的一条线索。该项目历时约两个月，对多个大型科技平台的图像处理基础设施进行了排查。整个项目消耗的模型 Token 成本不足 3,000 美元。

OpenAI 针对其一侧的账户接管漏洞，向 Hacktron 支付了 6,500 美元漏洞赏金。此后，该公司已收紧社区登录令牌的权限，并撤销了受影响的令牌和会话。

Three security researchers atHacktron AI found a memory-corruption bug in a widely used image library. Finding it was the easy part.

The hard part was turning it into something that works on a real server, so on July 24 they handed that job to Anthropic’s Claude Opus 4.8. The model managed it only with the operating system’s memory randomization switched off. With the protection on — this is the way every production box runs it — nothing it wrote held up.

That evening, Anthropic released Opus 5.

The researchers came back the next morning with the same bug and the new model. Roughly three hours later, Opus 5 had a working ARM64 exploit running against a Mac on their desk. About four hours after that, they had remote code execution against a test forum.

Less than 72 hours after they started, they were reading from OpenAI’s private monorepo — using an OpenAI employee’s Codex account to open a pull request against a README, then stopping there.

Hacktron AI published its account of the incident on its website this week.

It started with an image

The bug wasn’t in anything OpenAI wrote. Hacktron was testing community.openai.com, the company’s user forum, which runs on Discourse — the same off-the-shelf forum software behind thousands of other sites.

Discourse normally screens uploaded images with FastImage. But FastImage doesn’t handle HEIC and HEIF, so those files get passed to ImageMagick instead, and ImageMagick decodes them with libheif. The version running in the Debian 12 base image the forum used, 1.19.7, had a heap buffer overflow that a specially crafted file could trigger.

A fix had landed upstream the previous year. But the commit wasn’t documented as a security fix and never got a CVE, so it never triggered a backport into the Debian package the forum was using — a patched bug that stayed exploitable because nobody labeled it.

The researchers adapted the exploit for the x86-64 and jemalloc configuration Discourse runs, and a malformed HEIC image was enough to trigger remote code execution.

Discourse later confirmed the vulnerability in security advisory GHSA-vhm9-85gw-x335, rating the upstream libheif flaw — tracked as CVE-2026-32882 — 8.8 out of 10 on the CVSS severity scale. The New Stack has reached out to Hacktron AI for additional details about the researchers’ use of Claude and will update this story if we hear back.

One exploit, a much larger path

Code execution on a forum is a bad day for the forum. But it shouldn’t be a bad day for the company that owns the forum. This is where the chain crossed into something that was OpenAI’s own. Hacktron then found a flaw in OpenAI’s single sign-on system: sign-in tokens issued for the forum carried excessive permissions, granting full API access to the linked ChatGPT and Codex accounts. Some of those accounts belonged to OpenAI employees.

One employee’s Codex account was connected to OpenAI’s GitHub environment, opening a path to the company’s private repositories. Hacktron says other accounts could have exposed connected services including Slack and email.

The team stopped there. Using Codex, they made a harmless documentation change against OpenAI’s private openai/openai monorepo and opened a pull request — enough to prove the access was real, and nothing more. Hacktron’s write-up says the pull request’s details were redacted at OpenAI’s request.

From assistant to exploit developer

Up to this point, those three experienced researchers were still in the loop. So Hacktron ran the experiment again with the humans mostly out of it.

They put Claude in an autonomous agent loop — giving it a goal, a target, and time to keep working — pointed at a Discourse instance of their own. The model got there on its own, achieving remote code execution and demonstrating it by reading /etc/hosts from inside the container.

Getting it started took one piece of misdirection: Opus refused to write an exploit aimed at a live remote host. So the team proxied their own instance through rce.ee/ctf-forum, a URL that made the target look like it was part of a capture-the-flag exercise.

Memory-corruption exploitation has always been specialist work, invovling memory layouts, allocators, operating system internals, and protections to make all of it wildly unreliable. Hacktron’s run signals a meaningful share of that work might be able to be delegated to AI now. It also suggests the line between security research and attack development is — from the model’s side, anyway — partly a question of what you consider a target.

The full chain

Put together, the attack looked like this:

HEIF upload → libheif overflow → code execution on the forum → over-permissioned SSO tokens → employee ChatGPT/Codex account → connected GitHub → pull request in openai/openai

A two-month project, under $3,000

The OpenAI intrusion was one thread in a broader project the team called “HEIF Heist,” a roughly two-month sweep of image-processing infrastructure across multiple major technology platforms. The whole effort consumed less than $3,000 in model tokens.

OpenAI paid Hacktron a $6,500 bounty for the account-takeover flaw on its side. It has since narrowed the permissions on community sign-in tokens and revoked the affected tokens and sessions.

YOUTUBE.COM/THENEWSTACK Tech moves fast, don't miss an episode. Subscribe to our YouTube channel to stream all our podcasts, interviews, demos, and more. SUBSCRIBE

Group Created with Sketch.