通过堆溢出与 SSO 配置错误攻陷 OpenAI 内部代码库
英文标题：🔶 A heap overflow and SSO misconfiguration to compromise OpenAI internal repos
研究团队 Hacktron 表示，其将 `libheif` 堆缓冲区溢出、Debian 安全补丁缺失、Discourse 图片上传链路及 OpenAI SSO 身份配置错误串联，曾可接管 OpenAI 论坛活跃成员的 ChatGPT 和 Codex 账户。团队称，他们以一名 OpenAI 员工的 Codex 账户在内部单体代码库创建 PR #1186742，以在不读取敏感代码的情况下证明访问权限，并获得 OpenAI 6,500 美元漏洞奖金。报告指出，AI 模型显著降低了将内存破坏漏洞适配为可靠利用链的成本和时间，整个更广泛的 HEIF Heist 研究耗时两个月、Token 成本不足 3,000 美元。对开发者而言，报告建议及时更新 `libheif`、`libde265` 和 Discourse，并对不受信任的 HEIF/AVIF 图像解码实施禁用或沙箱隔离等纵深防御措施。
9.2 KB
9.2 KB
10.0 KB
1.4 KB
309.5 KB
9.9 KB
23.4 KB
59.3 KB
93.6 KB
32.8 KB
9.1 KB
9.1 KB
1.0 MB
中文
引言
2026 年 7 月 25 日，我们将两个严重漏洞串联起来，攻陷了多名 OpenAI 员工的 ChatGPT 账户。借助这些账户，我们随后能够访问 OpenAI 内部代码库，以及潜在的许多其他连接器。
为证明我们确实获得了所认为的访问权限，同时又不让自己接触任何敏感信息，我们使用该员工的 Codex，在 OpenAI 内部单体代码库 openai/openai 中创建了 PR #1186742。
利用链
- libheif 图像解码器
- Debian 缺失安全回移补丁
- ImageMagick 使用 libheif
- Discourse 图片上传
- OpenAI 论坛 community.openai.com
- OpenAI SSO 身份漏洞
- ChatGPT / Codex 账户访问
- GitHub 已连接集成
- 内部代码库 OpenAI
直到两个月前，任何登录 OpenAI 自有帮助论坛（community.openai.com) 的用户或 OpenAI 员工，其 ChatGPT 和 Codex 账户都可能被接管。由于用户可以将各种服务连接至 Codex 和 ChatGPT，我们理论上可访问的范围极大，包括 GitHub、Slack 和电子邮件。
从最初发现到获得 OpenAI 代码库访问权限，整个时间线不足 72 小时。
我们立即向 OpenAI 和 Discourse 报告了初始漏洞，并与他们协作协调修复。我们感谢他们对细节的重视以及对这一问题的快速处理。OpenAI 还向我们支付了 6,500 美元奖金。
我们在此提供了披露流程的完整时间线。本文其余部分将详细说明我们如何发现这两个漏洞、如何使用 Claude 模型，以及我们从这次经历中获得的启示。
背景
几个月前，由 Harsh Jaiswal 领导、Mohan Pedhapati 和 Rahul Maini 共同参与的 Hacktron 团队开始研究前沿 AI 公司，以寻找安全漏洞。这促使我们发现了 OpenAI 身份基础设施中的 SSO 配置错误，以及 OpenAI 所用社区论坛中的 libheif RCE 漏洞。
此后，我们将研究扩展为 HEIF Heist：这是一项持续数月的调查，追踪 libheif 在 Slack、Meta、GitHub Enterprise、Ruby on Rails 以及 Next.js、Astro、Gatsby 等 Node.js 框架中的使用情况。数量惊人的广泛使用软件依赖这一个图像处理库。
如果你的应用处理用户可控图像，并接受 .heic/.heif/.avif 图像，那么它极有可能受到影响。如需任何形式的协助，请通过 hello@hacktron.ai 联系我们。
警告
**补丁通知：**如果你自行托管 Discourse，请立即重建安装。较旧的 Docker 镜像可能包含存在漏洞的 libheif 依赖项，攻击者可通过图片上传执行代码。在 /var/discourse 中执行 git pull，随后运行 ./launcher rebuild app；仅通过 Web 界面更新可能不会替换底层图像组件。Discourse 托管客户已完成修复。参见安全公告。
OpenAI 使用 Discourse 作为论坛，并通过 auth.openai.com 提供“使用 OpenAI 登录”。在深入了解 OpenAI 的服务和基础设施后，我们有理由相信，攻陷论坛可通过这一身份流程进入更广泛的 OpenAI 服务。为验证这一假设，我们首先需要在 OpenAI 的某项服务上取得远程代码执行能力，例如 Discourse 社区论坛。
尽管 Discourse 应用本身并不容易成为目标（我们过去曾研究过它），但我们认为可以从某个依赖项入手。
libheif 中的堆缓冲区溢出
7 月 23 日，我们开始审查 Discourse 的图片上传流水线，并发现 HEIC 和 HEIF 文件会走一条不同寻常的路径。Discourse 通常使用 FastImage 进行图像检查，但由于 FastImage 不支持 HEIF，它会将这些文件交给 ImageMagick 的 magick 命令进行转换。2 这使底层 libheif 解析器直接暴露于攻击者可控的文件。
我们使用 Discourse Docker 镜像开启了一个 Opus 4.8 会话，并要求它检查已安装的 libheif 软件包是否存在安全问题。一段时间后，它发现部分特定安全修复未被回移至该 libheif 软件包。这使得在 HEIC 解码期间可触发堆缓冲区溢出，从而获得越界读写（OOB R/W）原语。
有趣的是，漏洞代码在前一年已在上游被修改，但该提交未被标注为安全修复，也未获得 CVE。3 这或许是 Debian 12 和 13 未能及时获得相关安全回移补丁的原因。由于 Discourse 的 Docker 镜像基于 Debian 12，它安装了存在漏洞的 libheif 1.19.7 版本。当时，即便 Debian 13 仍提供存在漏洞的 1.19.8 版本。此后，Debian 已于 2026 年 8 月 8 日发布 Debian 13 的安全更新。4
7 月 24 日，我们使用 Opus 4.8 开发出一个可工作的 ImageMagick/libheif 代码执行利用，在关闭 ASLR 的情况下运行。随后，我们启动多个独立会话，尝试使其在启用 ASLR 的 Discourse 默认配置下稳定运行，但没有取得成果。
Opus 5 发布
当晚，Anthropic 发布了 Claude Opus 5.5。我们开启了一个新会话，它首先在 3 小时内针对本地 Mac 生成了可用的 ARM64 利用。随后，我们要求它将该利用移植到 Discourse 使用的 x86-64 环境和 jemalloc 配置。
到 7 月 25 日上午 6:00，我们已确认可通过图片上传在本地实现 RCE。随后，我们让 Claude 在自己的 Discourse Cloud 实例上以自主 /goal 循环运行，并通过 rce.ee/ctf-forum 进行代理，将其伪装成 CTF 目标，因为 Opus 拒绝为远程实例编写利用代码。
当我们在上午 10:00 再次检查时，该 Agent 已在 Discourse Cloud 上实现 RCE，并通过读取 /etc/hosts 证明了访问能力。利用生成的利用脚本，我们成功在 OpenAI 的实例上获得 RCE。
在确认可以无需交互地接管论坛活跃成员的 ChatGPT/Codex 账户后，我们立即将报告发送给 OpenAI。随后，我们接管了一名 OpenAI 员工的账户，其 Codex 已连接至 OpenAI 的 GitHub 组织。为了在不实际访问任何内部代码的前提下演示影响，我们向该员工的 Codex 账户发送提示词，要求其在 OpenAI 内部单体代码库中为我们创建一个 PR。之后，我们停止了进一步测试。
我们更新了 BugCrowd 提交内容，补充影响证明，并提醒了 OpenAI 安全团队。我们还为 Discourse 准备了一份报告，并通过其 HackerOne 项目提交。Discourse 在周六收到报告、周日回复，并在周一完成修复（速度值得称赞）。他们还立即开始对 ImageMagick 进行沙箱化。
我们希望强调：用于实现权限升级的漏洞并非 Discourse 特有。这是一个 OpenAI SSO 问题，它将论坛攻陷转化为对 ChatGPT 和 Codex 的访问。若任何使用 OpenAI SSO 的 OpenAI 第一方或第三方服务遭到攻陷，都会导致同样的访问权限——Discourse 只是验证这一点的一种途径。
发现这些漏洞的成本
对于 Agent 而言，Discourse 和 OpenAI 攻击只花了几天时间，而人工投入仅为数小时。针对 Slack、Zoom、Meta 等更多目标的整个 HEIF Heist 研究项目耗时两个月，Token 总成本不足 3,000 美元，由三名研究人员完成。将利用适配到每一家新公司通常只需一到两天。
我们观察到，每一个新模型的能力都在持续增强，本文展示的 Discourse 利用就是明证。Opus 4.8 在多个会话中都难以生成一个能在启用 ASLR 条件下运行的有效利用。Opus 5 发布后数小时内，我们将同一个问题交给它，它便成功完成。更广泛的研究活动中，我们还观察到从 Opus 5 到 GPT-5.6 Sol 的又一次明显跃升：当时我们必须在除“目标系统存在漏洞”以外对目标一无所知的情况下利用该漏洞。
对每个目标，测试均从一次图像上传开始。接着，我们将内存破坏转化为可靠的内存泄露或 Shell，通常并不知道确切的 libheif 版本、libc 版本或部署环境。AI 在几乎一无所知的情况下开始，并在一到两天内为每家公司适配利用。除 Shopify 以外，我们不知道有任何公司检测到这些活动——即使我们发送了数千张图片，且其图像处理器反复崩溃。
当代码执行落在沙箱或受限环境中时，模型还能协助进行权限提升、横向移动和绕过现有防御。这并非完全自主的黑客攻击，熟练的人类指导仍然重要，但一个小团队能够完成的工作量大幅增加。
结语
长期以来，软件一直受益于某种“复杂性带来的安全性”。代码乃至漏洞本身可以是公开的，但要将一个 Bug 转化为可靠利用，仍需要罕见的专业知识、大量时间和对目标环境的了解。已知内存破坏漏洞的实战化成本高昂，而零日漏洞大多只用于价值最高的目标。
这从来不是真正的安全边界，但在实践中，它确实保护了普通公司免受软件漏洞的影响。AI 正在消除这种保护，将更多稀缺专业能力转化为算力。过去需要资源充足的团队花费数月才能完成的工作，现在可以压缩到数天。
安全假设必须跟上攻击者能力的发展。现实的威胁模型应考虑当今漏洞利用的经济性，而不是依赖关于哪些人能够发起复杂攻击的过时假设 6。
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 已被后续安全修复取代。发行版软件包可能会在较旧的上游版本号下携带回移修复，因此也应检查软件包安全公告。7 4 - **纵深防御。**鉴于 ISO 基础媒体文件格式的复杂性，以及解码器更新的速度，未来仍可能出现内存安全漏洞。生产架构应在不需要时禁用对不受信任 HEIF/AVIF 的解码，或将图像处理流水线隔离在经过加固的临时沙箱中。ImageMagick 的安全策略支持限制可接受的格式和资源使用量。8
致谢
我们感谢 Sudanshu Rajhbhar 提供技术协助，并感谢 Zayne Zhang、Fabian Faessler、Robert Chen 和 Jessica Ruan 校对、审阅草稿并提供改进本文的反馈。
参考资料
与本研究背后的团队合作。
Hacktron 汇集顶尖 CTF 研究人员、经验丰富的红队成员和进攻性安全研究人员。我们使用 AI 加速安全研究，在恶意行为者之前发现并消除广泛受信任软件中的漏洞。我们正持续在前沿实验室及其他互联网关键系统中开展研究。如果你负责保护其中之一，我们希望能与你合作。
English / 原文
Intro
On July 25, 2026, we chained two critical vulnerabilities to compromise multiple OpenAI employees’ ChatGPT accounts. With these accounts, we could then access internal OpenAI repositories, and potentially many other connectors.
To prove we had in fact gained the access we believed without allowing ourselves to learn any sensitive information, we used the employee’s Codex to open a PR #1186742 in OpenAI’s internal monorepo openai/openai.
Exploit chain
- libheif Image decoder
- Debian Missing security backport
- ImageMagick Uses libheif
- Discourse Image uploads
- OpenAI forum community.openai.com
- OpenAI SSO Identity flaw
- ChatGPT / Codex Account access
- GitHub Connected integration
- Internal repos OpenAI
Until two months ago, any user or OpenAI employee logging into OpenAI’s own help forum (community.openai.com) could have had their ChatGPT and Codex accounts taken over. Since people can connect various services to Codex and ChatGPT, the scope of what we could theoretically access was huge, including GitHub, Slack and emails.
The entire timeline from initial discovery to access to OpenAI repo access took place in less than 72 hours.
We immediately reported the initial vulnerability to OpenAI and Discourse and worked with them to coordinate the patch. We appreciate their attention to detail and fast resolution of this issue. OpenAI also paid us a $6,500 bounty.
We provide a full timeline of the disclosure process here. The rest of the post details how we discovered the two vulnerabilities, how we used claude models, as well as our takeaways from this experience.
Background
A few months ago, our team at Hacktron, led by Harsh Jaiswal alongside Mohan Pedhapati and Rahul Maini, began researching frontier AI companies to find security vulnerabilities. This led us to discover an SSO misconfiguration in OpenAI’s identity infrastructure and a libheif RCE in the community forum used by OpenAI.
We’ve since expanded the research into HEIF Heist, a multi-month investigation tracing libheif across Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks such as Next.js, Astro, and Gatsby. A surprising amount of widely-used software depends on this one image-processing library.
If your application processes user-controlled images and accepts .heic/.heif/.avif images, it is highly likely it is affected. Please reach out to us at hello@hacktron.ai if you need any kind of assistance.
Warning
Patch notice: If you self-host Discourse, rebuild your installation now. Older Docker images may contain a vulnerable libheif dependency that permits code execution through an image upload. Run git pull followed by ./launcher rebuild app from /var/discourse; a web-interface update alone may not replace the underlying image. Discourse-hosted customers have already been patched. See the security advisory.
OpenAI uses Discourse for their forum and allows “Sign in with OpenAI” through auth.openai.com. After getting a good understanding of OpenAI’s services and infrastructure, we had reason to believe that compromising the forum could create a path into broader OpenAI services through this identity flow. To test that hypothesis, we first needed remote code execution on an OpenAI service like the Discourse community forum.
While the Discourse app itself is actually not an easy target (we have looked into it in the past), we thought we could go after a dependency.
Heap buffer overflow in libheif
On July 23, we started reviewing Discourse’s image-upload pipeline, and we found that HEIC and HEIF files followed an unusual path. Discourse normally used FastImage for image checks, but because FastImage did not support HEIF, it passed those files to ImageMagick’s magick command for conversion.2 That exposed the underlying libheif parser directly to attacker-controlled files.
We started an Opus 4.8 session with the Discourse Docker image and asked it to inspect the installed libheif package for security issues. After a while, it found that some particular security fixes were not back-ported to the libheif package. This allowed an heap buffer overflow leading to OOB R/W primitives during HEIC decoding.
Interestingly, the vulnerable code had been changed upstream the previous year, but the commit was not documented as a security fix and received no CVE.3 This might be a reason why Debian 12 and 13 have not received the security relevant backports in time. Because Discourse’s Docker image was based on Debian 12, it installed the vulnerable libheif version 1.19.7. Even Debian 13 still shipped the vulnerable version 1.19.8 at the time. Since then, Debian has published its security update for Debian 13 on August 8, 2026. 4
On July 24, we used Opus 4.8 to develop a working ImageMagick/libheif code-execution exploit with ASLR disabled. We then launched several separate sessions to make it reliable against Discourse’s default configuration with ASLR enabled, which wasn’t fruitful.
Opus 5 Released
That evening, Anthropic released Claude Opus 5.5We started a new session, which first produced a working ARM64 exploit for a local Mac within 3 hours. We then asked it to port the exploit to the x86-64 environment and jemalloc configuration used by Discourse.
By 6:00 a.m. on July 25, we had confirmed local RCE through an image upload. We then placed Claude in an autonomous /goal loop against our own Discourse Cloud instance, proxied through rce.ee/ctf-forum to make it look like a CTF target as Opus refused write exploit for remote instances.
When we checked again at 10:00 a.m., the agent had achieved RCE on Discourse Cloud and demonstrated access by reading /etc/hosts. Using the generated exploit script, we managed to get RCE on OpenAI’s instance.
After we had confirmed our hypothesis of no interaction account takeover of ChatGPT/Codex accounts from active members of the forum, we immediately sent our report to OpenAI. We then took over an OpenAI employee’s account, whose Codex was connected to OpenAI’s Github organization. To demonstrate impact without actually accessing any internal code, we sent a prompt to this employee’s Codex account to open a PR for us in OpenAI’s internal monorepo. Then we stopped any further testing.
We updated the BugCrowd submission with the impact proof and alerted OpenAI security. We also prepared a report for Discourse and reported it to their HackerOne program. Discourse received the report on a Saturday, replied on Sunday, and had a fix by Monday (kudos for speed). They also immediately started sandboxing ImageMagick.
We want to emphasize that the vulnerability to escalate is not Discourse-specific. It is an OpenAI SSO issue that turned the forum compromise into access to ChatGPT and Codex. If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to same access - Discourse was merely one way of proofing it.
Costs of finding these vulnerabilities
The Discourse and OpenAI hack took a few days for an agent, and just a few hours of human time. The whole HEIF Heist research project going after Slack, Zoom, Meta, adn more took two-months, cost less than $3,000 in tokens in total, and was conducted by three researchers. Adapting the exploit to each new company usually took only one or two days.
We observed that every new model is getting increasingly capable, as evident by the Discourse exploit presented in this report. Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5’s release, we gave it the same problem and it succeeded. Across the broader campaign, we saw another clear jump from Opus 5 to GPT-5.6 Sol, when we had to exploit the vulnerability without knowing anything about the target system besides that it’s vulnerable.
For each target, testing began with an image upload. From there, we turned memory corruption into a reliable memory leak or shell, usually without knowing the exact libheif version, libc version, or deployment environment. The AI started almost blind and adapted the exploit for each company within one or two days. We are not aware of any company that detected the activity except Shopify, even after thousands of images were sent and their image processors repeatedly crashed.
When code execution landed inside a sandbox or restricted environment, the models also helped with privilege escalation, lateral movement, and bypassing existing defenses. This was not completly autonomous hacking, and skilled human guidance remained important, but the amount of work a small team could perform increased dramatically.
Epilogue
Software has long benefited from a kind of security through complexity. The code and even the vulnerability could be public, but turning a bug into a reliable exploit still required rare expertise, significant time, and knowledge of the target environment. Known memory corruption vulnerabilities were expensive to operationalize, while zero-days were mostly reserved for the highest-value targets.
This was never a real security boundary, but it protected ordinary companies in practice from software vulnerabilities. AI is removing that protection by turning more of this scarce expertise into compute. Work that once required a well-resourced team and months of effort can now be compressed into days.
Security assumptions must catch up with attacker capabilities. A realistic threat model should take into account the economics of exploitation today, instead of relying on outdated assumptions 6 about who can carry out sophisticated attacks.
Hacktron’s mission is to help secure the internet by finding and eliminating vulnerabilities in widely trusted software before malicious actors do. We are continuing this research across frontier labs and other internet-critical systems. If you are responsible for securing one of them, we would like to work with you.
Versions affected and patches
HEIF Heist is not tied to a single version. It targets an entire ecosystem of vulnerabilities across multiple release families (e.g. 1.19.x, 1.20.x, 1.22.x, 1.23.x). Any deployment lacking the latest upstream security patches is potentially vulnerable.
- Update upstream. Install the latest security-patched
libheifandlibde265packages through your distribution’s security channel or an upstream release. As of September 14, 2026, the latest upstreamlibheifsecurity release is v1.23.4; v1.23.2 has been superseded by further security fixes. Distribution packages may carry backported fixes under an older upstream version number, so check the package security advisory as well.7 4 - Defense in depth. Given the complexity of the ISO base media file format and the pace of decoder updates, future memory-safety flaws are likely. Production architectures should disable untrusted HEIF/AVIF decoding where it is not needed, or isolate image-processing pipelines inside hardened, ephemeral sandboxes. ImageMagick’s security policy supports restricting accepted formats and resource usage. 8
Acknowledgements
We thank Sudanshu Rajhbhar for technical assistance, and Zayne Zhang, Fabian Faessler, Robert Chen, and Jessica Ruan for proofreading, reviewing drafts, and providing feedback that improved this post.
References
Work with the team behind this research.
Hacktron brings together top CTF researchers, experienced red teamers, and offensive security researchers. We use AI to accelerate security research, finding and eliminating vulnerabilities in widely trusted software before malicious actors do. We’re continuing our research across frontier labs and other internet-critical systems. If you’re responsible for securing one of them, we’d like to work with you.