A heap overflow and SSO misconfiguration to compromise OpenAI internal repos

查看原文 / View Original 编辑 / Edit

A heap overflow and SSO misconfiguration to compromise OpenAI internal repos

堆溢出与 SSO 配置错误导致 OpenAI 内部代码库被攻破

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. 简介：2026 年 7 月 25 日，我们通过串联两个关键漏洞，成功攻破了多名 OpenAI 员工的 ChatGPT 账户。利用这些账户，我们能够访问 OpenAI 的内部代码库，以及潜在的许多其他连接器。为了证明我们确实获得了预期的访问权限，同时避免获取任何敏感信息，我们利用该员工的 Codex 权限在 OpenAI 的内部单体仓库 openai/openai 中提交了一个 PR #1186742。

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. 直到两个月前，任何登录 OpenAI 官方帮助论坛（community.openai.com）的用户或员工，其 ChatGPT 和 Codex 账户都有可能被劫持。由于用户可以将各种服务连接到 Codex 和 ChatGPT，理论上我们可访问的范围非常广泛，包括 GitHub、Slack 和电子邮件。从最初发现漏洞到获得 OpenAI 代码库访问权限，整个过程耗时不到 72 小时。

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. 我们立即向 OpenAI 和 Discourse 报告了最初的漏洞，并与他们协作修复。我们感谢他们对细节的关注以及对该问题的快速解决。OpenAI 还向我们支付了 6,500 美元的赏金。我们在此提供了披露过程的完整时间线。本文其余部分将详细介绍我们如何发现这两个漏洞、如何使用 Claude 模型，以及我们从这次经历中获得的经验教训。

Timeline (25 July 2026 – 01 Sep 2026)

时间线（2026 年 7 月 25 日 – 2026 年 9 月 1 日）

  • 25 July 2026 05:00–06:00 UTC Initial Finding: HacktronAI team obtained remote code execution (RCE) and administrative access to the Discourse environment hosted at community.openai.com. 2026 年 7 月 25 日 05:00–06:00 UTC 初步发现： HacktronAI 团队在 community.openai.com 托管的 Discourse 环境中获得了远程代码执行 (RCE) 和管理权限。

  • 25 July 2026 08:00–10:00 UTC Bugcrowd Submission: After confirming the cross-product impact, the team coordinated internally on the responsible disclosure process and submitted a report through OpenAI’s Bug Bounty Program on Bugcrowd. 2026 年 7 月 25 日 08:00–10:00 UTC Bugcrowd 提交： 在确认了跨产品影响后，团队内部协调了负责任的披露流程，并通过 Bugcrowd 上的 OpenAI 漏洞赏金计划提交了报告。

  • 25 July 2026 13:30–15:30 UTC OpenAI Employee Account Access & Proof of Concept: To demonstrate the practical impact of the vulnerability, we created a harmless proof-of-concept pull request in OpenAI’s internal monorepo. We updated the existing Bugcrowd submission with these findings, reached out to friends at OpenAI on Twitter/X to notify them directly, and ceased all further testing at approximately 15:30 UTC. 2026 年 7 月 25 日 13:30–15:30 UTC OpenAI 员工账户访问与概念验证： 为了证明漏洞的实际影响，我们在 OpenAI 的内部单体仓库中创建了一个无害的概念验证 Pull Request。我们用这些发现更新了现有的 Bugcrowd 提交，通过 Twitter/X 联系了 OpenAI 的朋友直接通知他们，并于 UTC 时间 15:30 左右停止了所有进一步测试。

  • 25 July 2026 22:49:45 UTC OpenAI-Side Fix Confirmed: OpenAI replied to the report confirming the issue had been fixed, roughly 14 hours after the initial submission. 2026 年 7 月 25 日 22:49:45 UTC OpenAI 端修复确认： OpenAI 回复报告确认问题已修复，距离最初提交约 14 小时。

  • 26 July 2026 Discourse Responded: Discourse replied to the report on Sunday. 2026 年 7 月 26 日 Discourse 响应： Discourse 在周日回复了报告。

  • 27 July 2026 Discourse Fix Ready: Discourse had a fix ready by Monday and added image-processing sandboxing as defense in depth. 2026 年 7 月 27 日 Discourse 修复就绪： Discourse 在周一准备好了修复程序，并增加了图像处理沙箱作为纵深防御。

  • 01 Sep 2026 OpenAI Rewarded $6,500 Bounty and Marked Resolved: OpenAI comment — To clarify the scope of that award: testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program. The award recognizes the OpenAI-side finding, not the actions against Discourse. 2026 年 9 月 1 日 OpenAI 奖励 6,500 美元赏金并标记为已解决： OpenAI 评论——为澄清该奖励的范围：针对 Discourse 托管的 community.openai.com 的测试明确排除在我们的漏洞赏金计划之外。该奖励旨在表彰 OpenAI 端的发现，而非针对 Discourse 的行为。

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. 几个月前，我们 Hacktron 团队（由 Harsh Jaiswal 领导，Mohan Pedhapati 和 Rahul Maini 参与）开始研究前沿 AI 公司以寻找安全漏洞。这使我们发现了 OpenAI 身份基础设施中的 SSO 配置错误，以及 OpenAI 所使用的社区论坛中存在的 libheif RCE 漏洞。

Hacking community.openai.com

入侵 community.openai.com

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. 警告修复通知： 如果您自托管 Discourse，请立即重建您的安装。旧的 Docker 镜像可能包含易受攻击的 libheif 依赖项，允许通过图像上传执行代码。请在 /var/discourse 目录下运行 git pull，然后运行 ./launcher rebuild app；仅通过 Web 界面更新可能无法替换底层的镜像。Discourse 托管的客户已完成修复。

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. OpenAI 使用 Discourse 作为其论坛，并允许通过 auth.openai.com 进行“使用 OpenAI 登录”。在充分了解 OpenAI 的服务和基础设施后，我们有理由相信，攻破该论坛可以通过此身份验证流程进入更广泛的 OpenAI 服务。为了验证这一假设，我们首先需要在像 Discourse 社区论坛这样的 OpenAI 服务上实现远程代码执行。

Heap buffer overflow in libheif

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. That exposed the underlying libheif parser directly to attacker-controlled files. 7 月 23 日，我们开始审查 Discourse 的图像上传管道，发现 HEIC 和 HEIF 文件遵循一条不同寻常的路径。Discourse 通常使用 FastImage 进行图像检查，但由于 FastImage 不支持 HEIF，它将这些文件传递给 ImageMagick 的 magick 命令进行转换。这使得底层的 libheif 解析器直接暴露于攻击者控制的文件之下。

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. 我们使用 Discourse Docker 镜像启动了一个 Opus 4.8 会话，并要求它检查已安装的 libheif 包是否存在安全问题。一段时间后，它发现一些特定的安全修复程序没有被反向移植到 libheif 包中。这导致了堆缓冲区溢出，从而在 HEIC 解码期间产生了越界读写（OOB R/W）原语。

← 返回新闻列表 / Back to news list