# Hacktron 复盘利用 libheif 漏洞与 OpenAI SSO 缺陷入侵 OpenAI 论坛并接管员工 ChatGPT 账号 - 来源：Hacker News 热门（buzzing.cc 中文翻译） - 作者：Handy-Man - 发布时间：2026-09-18 12:45 - AIHOT 分数：84 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.news/items/cmu6idvti04i9ro0fktczvi9g - 原文链接：https://www.hacktron.ai/blog/hacking-openai ## 精选理由 作者以第一手复盘展示了 AI 智能体如何把漏洞利用成本压缩到数天数千美元，安全团队可据此重估自身威胁模型。 ## AI 摘要 Hacktron 团队披露 2026 年 7 月 25 日 chained libheif 堆缓冲区溢出与 OpenAI SSO 身份缺陷，攻破 community.openai.com 并接管多名员工 ChatGPT/Codex 账号，用员工 Codex 在 OpenAI 内部 monorepo 开出无害 PR 作为证明，全程不到 72 小时。 ## 正文 简介 2026 年 7 月 25 日，我们串联了两个严重漏洞，攻破了多名 OpenAI 员工的 ChatGPT 账户。借助这些账户，我们随后得以访问 OpenAI 内部代码仓库，并有可能访问许多其他连接器。 为了证明我们确实获得了自认为已获取的访问权限，同时又不让自己接触到任何敏感信息，我们使用该员工的 Codex 在 OpenAI 内部 monorepo 中提交了一个 PR #1186742 openai/openai。 媒体内容 · 前往原文查看 漏洞利用链 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 模型，以及我们从中获得的经验教训。 2026 年 7 月 25 日 05:00–06:00 UTC 初步发现 HacktronAI 团队获得了对托管于 community.openai.com 的 Discourse 环境的远程代码执行（RCE）和管理员访问权限。 2026 年 7 月 25 日 08:00–10:00 UTC Bugcrowd 提交 在确认了跨产品影响后，团队内部就负责任披露流程进行了协调，并通过 Bugcrowd 上的 OpenAI Bug Bounty Program 提交了一份报告。 2026 年 7 月 25 日 13:30–15:30 UTC OpenAI 员工账户访问权限与概念验证 为了演示该漏洞的实际影响，我们在 OpenAI 的内部 monorepo 中创建了一个无害的概念验证 pull request（应 OpenAI 要求，链接已隐去）。我们用这些发现更新了现有的 Bugcrowd 提交，通过 Twitter/X 联系了 OpenAI 的朋友以直接通知他们，并在大约 15:30 UTC 停止了所有进一步测试。 2026 年 7 月 25 日 22:49:45 UTC OpenAI 方面修复已确认 OpenAI 回复了报告，确认该问题已修复，此时距最初提交大约 14 小时。 2026 年 7 月 25 日 通过 HackerOne 报告 Discourse 我们通过 Discourse 的 HackerOne 项目向其提交了一份报告。 2026 年 7 月 26 日 Discourse 已回应 Discourse 于周日回复了该报告。 2026 年 7 月 27 日 Discourse 修复方案就绪 Discourse 在周一之前就已备好修复方案，并新增了图像处理沙箱作为纵深防御措施。 2026 年 7 月 28 日 Discourse 发布安全公告 Discourse 发布了 GHSA-vhm9-85gw-x335，其中包含补丁和重建指南。 2026 年 9 月 1 日 OpenAI 发放 6,500 美元赏金并标记为已解决 OpenAI 评论——为澄清该奖励的范围：针对 Discourse 托管的 community.openai.com 的测试已被明确排除在我们的漏洞赏金计划之外。该奖励认可的是 OpenAI 一侧的发现，而非针对 Discourse 的行为。 背景 几个月前，我们 Hacktron 的团队在 Harsh Jaiswal 的带领下，与 Mohan Pedhapati 和 Rahul Maini 一起，开始对前沿 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 联系我们。 入侵 community.openai.com 警告 补丁通知：如果你自行托管 Discourse，请立即重建你的安装。较旧的 Docker 镜像可能包含一个存在漏洞的libheif依赖项，该依赖项允许通过图片上传执行代码。请运行git pull随后运行./launcher rebuild app来自/var/discourse；仅更新 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 解析器直接暴露给了攻击者可控的文件。 我们启动了一个 Opus 4.8 会话，加载 Discourse Docker 镜像，让它检查已安装的 libheif 包是否存在安全问题。过了一会儿，它发现某些特定的安全修复并未被回溯移植到 libheif 包中。这使得在 HEIC 解码过程中出现堆缓冲区溢出，进而导致 OOB 读/写原语。 有趣的是，这段存在漏洞的代码在前一年就已在上游被修改，但该提交并未被记录为安全修复，也没有获得 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。随后我们启动了多个独立会话，试图让它在 Discourse 默认配置（启用 ASLR）下也能稳定生效，但未能成功。 Opus 5 发布 当晚，Anthropic 发布了 Claude Opus 5。5我们启动了一个新会话，它在 3 小时内首先产出了一个可在本地 Mac 上运行的 ARM64 漏洞利用程序。随后我们要求它将该漏洞利用程序移植到 x86-64 环境以及 Discourse 所使用的 jemalloc 配置上。 7 月 25 日凌晨 6:00，我们已通过图片上传确认了本地 RCE。随后，我们将 Claude 置于一个自主 /goal 循环中，针对我们自己的 Discourse Cloud 实例发起攻击，并通过 rce.ee/ctf-forum 代理，使其看起来像一个 CTF 靶标，因为 Opus 拒绝为远程实例编写漏洞利用程序。 当我们在上午 10:00 再次检查时，该智能体已在 Discourse Cloud 上实现了 RCE，并通过读取 /etc/hosts 证明了访问权限。利用生成的漏洞利用脚本，我们成功在 OpenAI 的实例上实现了 RCE。 在我们确认了论坛活跃成员的 ChatGPT/Codex 账户可在无交互情况下被接管的假设后，我们立即将报告发送给了 OpenAI。随后我们接管了一名 OpenAI 员工的账户，其 Codex 已连接到 OpenAI 的 Github 组织。 为了在不实际访问任何内部代码的情况下证明影响，我们向该员工的 Codex 账户发送了一条提示词，要求其在 OpenAI 的内部 monorepo 中为我们打开一个 PR。之后我们停止了任何进一步测试。 我们用影响证明更新了 BugCrowd 提交，并通知了 OpenAI 安全团队。我们还为 Discourse 准备了一份报告，并提交至其 HackerOne 项目。Discourse 在周六收到了报告，周日回复，并在周一之前完成了修复（速度值得称赞）。他们还立即开始对 ImageMagick 进行沙箱化。 我们要强调，这种可升级的漏洞并非 Discourse 独有。这是一个 OpenAI SSO 的问题，正是它把论坛被入侵变成了对 ChatGPT 和 Codex 的访问权限。任何使用 OpenAI SSO 的 OpenAI 一方或第三方服务一旦被攻破，都会导致同样的访问权限——Discourse 只不过是证明这一点的一种途径而已。 发现这些漏洞的成本 Discourse 和 OpenAI 的入侵对一个智能体来说只花了几天的工夫，人类投入的时间只有几个小时。整个 HEIF Heist 研究项目针对 Slack、Zoom、Meta 等更多目标，耗时两个月，token 总成本不到 $3,000，由三名研究人员开展。将漏洞利用适配到每一家新公司通常只需要一两天。 我们观察到，每一个新模型的能力都在不断增强，本报告中展示的 Discourse 漏洞利用就是明证。Opus 4.8 在启用 ASLR 的情况下，历经多个会话仍难以产出可用的漏洞利用。Opus 5 发布后数小时内，我们把同样的问题交给它，它就成功了。在更广泛的行动中，我们还看到从 Opus 5 到 GPT-5.6 Sol 的又一次明显跃升——当时我们必须在除了知道目标系统存在漏洞之外对其一无所知的情况下完成漏洞利用。 对于每一个目标，测试都从上传一张图片开始。从那里起，我们把内存破坏转化为可靠的 memory leak 或 shell，通常并不需要知道确切的 libheif 版本、libc 版本或部署环境。AI 几乎是在一无所知的情况下起步，并在一两天内为每家公司调整出可用的 exploit。据我们所知，除了 Shopify，没有任何一家公司检测到了这一活动，即便在发送了数千张图片、其图像处理器反复崩溃之后也是如此。 当代码执行落入沙箱或受限环境时，这些模型还帮助进行权限提升、横向移动以及绕过现有防御。这并非完全自主的黑客攻击，熟练的人类指导仍然很重要，但一个小团队所能完成的工作量急剧增加。 尾声 长期以来，软件一直受益于一种通过复杂性实现的安全。代码乃至漏洞本身都可以是公开的，但要把一个 bug 变成可靠的 exploit，仍然需要稀缺的专业知识、大量时间以及对目标环境的了解。已知的内存破坏漏洞要投入实战代价高昂，而 zero-day 大多留给价值最高的目标。 这从来都不是真正的安全边界，但在实践中，它保护了普通公司免受软件漏洞的侵害。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 的校对、审阅草稿和反馈，这些改进完善了本文。 参考文献 [1] xkcd #2347：依赖 ↩ [2] Discourse：对 HEIC 图像的支持 ↩ [3] libheif：简化叠加层重叠区域计算 ↩ [4] Debian DSA-6417-1：libheif 安全更新 ↩1 ↩2 [5] Anthropic：推出 Claude Opus 5 ↩ [6] RAND：保护 AI 模型权重的行动手册 ↩ [7] libheif v1.23.4 安全维护版本 ↩ [8] ImageMagick 安全策略 ↩ 与这项研究背后的团队合作。 Hacktron 汇聚了顶尖的 CTF 研究人员、经验丰富的红队成员以及攻防安全研究人员。我们利用 AI 加速安全研究，在恶意行为者之前发现并消除广受信任的软件中的漏洞。我们正在持续推进针对前沿实验室及其他互联网关键系统的研究。如果你负责其中某个系统的安全，我们希望能与你合作。