OpenAI 内部员工的 ChatGPT 账户遭入侵了，而帮上忙的“功臣”，竟然还是死对头 Anthropic 的 Claude。听起来有些讽刺，但这一切确实发生了。

近日，一家名为 Hacktron AI 的网络安全研究公司在 X 上披露，他们早在两个月前的 7 月 25 日，成功入侵了 OpenAI 的部分内部代码库，并获得了多名 OpenAI 员工 ChatGPT 和 Codex 账号的访问权限。

从发现漏洞到完成验证，整个过程不到 72 小时。最终，他们还通过 OpenAI 在 Bugcrowd 上的漏洞赏金计划，拿到了 6500 美元奖金。

消息传出后，很快引发了外界关注。毕竟，OpenAI 本身就是 AI 竞赛中最头部的一线玩家，却被研究人员借助另一家 AI 巨头的模型，一路摸进了内部开发环境。

那么，他们究竟是怎么做到的？

两个漏洞，串成一条「进入」OpenAI 的链路

事实上，几个月前，Hacktron AI 团队的三名研究员 Harsh Jaiswal、Mohan Pedhapati 和 Rahul Maini 就开始针对前沿 AI 公司展开安全漏洞研究。

在一次测试中，他们意外地发现了两个看起来并不相关的漏洞：

一个出现在 OpenAI 的身份基础设施中，是一处 SSO 配置问题；

另一个则藏在 OpenAI 社区论坛使用的第三方组件 libheif 中，存在可被利用的远程代码执行漏洞。

单看这两个漏洞，很难把它们和 OpenAI 内部系统联系起来。但研究人员很快发现，如果把它们串起来，就可能形成一条从社区论坛一路进入 OpenAI 内部的攻击链。

他们随后利用这条链路攻破了多名 OpenAI 员工的 ChatGPT 账户，并进一步发现，其中一名员工的 Codex 账号还连接着 OpenAI 的 GitHub 组织。

这意味着，研究人员获得的不再只是一个普通的 ChatGPT 账户，而是有机会进一步触达 OpenAI 内部开发环境。

入口不是 OpenAI 主站，而是社区论坛

回看整个事件发生的过程，值得注意的是，这条攻击链的起点，是 OpenAI 的社区论坛，而非 OpenAI 主站。

据研究人员披露，OpenAI 的社区论坛采用开源网络论坛软件 Discourse 搭建，并支持通过 auth.openai.com 使用“Sign in with OpenAI”登录。也就是说，论坛并不是一个完全孤立的站点，它和 OpenAI 的身份认证体系存在关联。

正如上文中提到的，Hacktron AI 的研究人员之前就已经发现，OpenAI 的身份基础设施存在一个 SSO 配置问题，因此他们产生了一个假设：

如果能够先拿下这个社区论坛，就有可能沿着身份认证链路进一步进入 OpenAI 的其他服务。

问题是，如何在这个论坛服务器上获得远程代码执行（RCE）能力？

Discourse 本身并不是一个容易下手的目标，Hacktron 团队此前也曾对其进行过研究。于是，他们把目光转向了 Discourse 所依赖的第三方软件。

7 月 23 日，Hacktron AI 研究人员开始检查 Discourse 的图片上传和处理流程，注意到 HEIC、HEIF 格式的图片（iPhone 等设备较常使用，类似 JPG）走了一条与普通图片不同的处理路径。

正常情况下，Discourse 会用 FastImage 这一图片处理组件检查用户上传的图片。但 FastImage 当时不支持 HEIF，于是这类图片会被交给另一个图片处理工具 ImageMagick 中的 magick 命令进行转换。转换过程中，ImageMagick 又会调用 libheif 解析 HEIF 图片。

这意味着，攻击者上传的 HEIF 文件，最终会直接进入底层的 libheif 图片解析器。

Opus 4.8 找 Bug 时卡住了，Opus 5 接手

研究进行到这一步，研究人员接下来开始检测 libheif 图片解析器是否存在安全问题。

当然，在 AI 时代，他们并不是完全依靠人工完成这项工作。在这一过程中，他们采用 Claude Opus 4.8，对 Discourse 的 Docker 镜像进行了分析，并让模型检查其中安装的 libheif 软件包是否存在安全问题。

经过一段时间的分析后，Claude 找到了一个关键问题：部分已经在上游修复的安全补丁，并没有及时回移植到当时使用的 libheif 软件包中。

这个问题存在于 HEIC 图片解码过程中，可以造成堆缓冲区溢出，并进一步形成越界读写能力，为代码执行创造条件。更麻烦的是，相关漏洞代码在前一年就已经被上游项目修改，但当时的提交没有明确标记为安全修复，也没有获得 CVE 编号。

Hacktron 研究人员认为，Debian 稳定版之所以还存在这个漏洞，可能是因为上游已经修好了，但 Debian 没有及时把这份修复补丁“搬回”自己正在使用的旧版本中。

当时 Discourse 使用的 Docker 镜像基于 Debian 12，安装的是存在问题的 libheif 1.19.7。即使是 Debian 13，在当时也仍然使用存在漏洞的 1.19.8 版本。

找到漏洞后，研究人员继续让 Claude Opus 4.8 尝试利用 ImageMagick/libheif 中的漏洞，看看能否进一步让程序执行攻击者指定的代码。

7 月 24 日，在关闭 ASLR（地址空间布局随机化）的情况下，Claude 已经能够帮助研究人员构建出可以工作的代码执行 Exploit。

但真正的问题在于，Discourse 的默认环境开启了 ASLR。研究人员随后启动了多个独立的 Claude 会话，尝试让模型进一步调整 Exploit，使其能够在默认配置下稳定工作。

这一次并没有取得理想结果。

转折出现在当晚。彼时 Anthropic 恰巧发布了 Claude Opus 5，研究人员采用了这个新模型重新开启了一轮测试。

据 Hacktron AI 介绍，新模型首先在不到 3 小时内，为本地 Mac 环境生成了一套可以正常工作的 ARM64 漏洞利用程序。随后，研究人员又要求 Claude 将这套 Exploit 移植到 Discourse 实际运行的 x86-64 环境，并适配其使用的 jemalloc 内存分配器配置。

到 7 月 25 日凌晨 6 点左右，他们已经确认，可以通过上传图片的方式在本地实现远程代码执行（RCE）。

接下来，研究人员把 Claude 放进一个自动化循环中，让它持续针对自己搭建的 Discourse Cloud 实例进行测试。为了让目标环境更接近 CTF 靶场，他们还通过 rce.ee/ctf-forum 对测试环境进行了代理。

这里还有一个细节值得注意。Hacktron 研究人员此前曾尝试让 Claude Opus 4.8 直接针对远程实例编写 Exploit，但模型拒绝了这一请求。因此，研究人员先让模型在自己的环境中完成漏洞利用，再逐步将其迁移到与真实目标相近的配置中。

上午 10 点左右，研究人员再次检查时，Claude 已经成功在 Discourse Cloud 上实现 RCE，并通过读取 /etc/hosts 文件证明了执行权限。

有了这套已经验证过的 Exploit，研究人员随后将其用于 OpenAI 的 Discourse 实例，并最终获得了远程代码执行权限。

从论坛 RCE 到 OpenAI 员工账号

拿到论坛服务器的执行权限后，研究人员进一步验证了此前关于 OpenAI 单点登录（SSO）的猜测。

他们发现，论坛上的活跃用户可以在特定条件下被进一步关联到 ChatGPT 和 Codex 账号。这意味着，最初看起来只是一个图片上传漏洞的安全问题，实际上还可能成为进入 OpenAI 其他服务的入口。

研究人员随后确认，他们能够接管一名 OpenAI 员工的账号，而该员工的 Codex 又连接到了 OpenAI 的 GitHub 组织。

为了证明这一权限确实能够触达 OpenAI 的内部开发环境，同时避免直接读取内部代码，研究人员采取了一个相对克制的验证方式：他们通过这名员工的 Codex 账号发出指令，让 Codex 在 OpenAI 的内部 Monorepo 中创建一个 Pull Request（PR）。

这个 PR 本身并不是为了修改或窃取代码，而是作为“已经获得内部仓库操作权限”的证明。完成这一验证后，研究人员立即停止了进一步测试。

OpenAI 约 14 小时后完成修复，也支付了 6500 美元赏金

随后，他们将这部分影响证明补充到提交给 OpenAI 的 BugCrowd 漏洞报告中，并再次通知 OpenAI 安全团队。

据研究团队披露，OpenAI 在收到报告约 14 小时后完成了自身一侧问题的修复。到了 9 月 1 日，OpenAI 向 Hacktron 支付了 6500 美元漏洞赏金。

OpenAI 通过 Hacktron 分享的一份声明进一步解释了这笔赏金的范围：

“需要明确的是，这笔奖励对应的范围是有限的：针对由 Discourse 托管的 community.openai.com 进行的测试，明确不属于我们的漏洞赏金计划范围。这笔奖励认可的是研究人员在 OpenAI 一侧发现的问题，而不是针对 Discourse 所采取的行动。”

与此同时，Hacktron 研究人员也将 Discourse 本身的漏洞单独报告给了其 HackerOne 项目。

据研究人员介绍，Discourse 在周六收到报告后，周日进行了回复，并在周一完成修复。同时，Discourse 也开始对 ImageMagick 的图片处理过程增加沙箱隔离，以降低类似漏洞被利用后进一步影响服务器的风险。

Hacktron 特别强调，这条攻击链中真正值得关注的并不是 Discourse 本身，而是 OpenAI 的 SSO 配置。

在他们看来，Discourse 只是一个用于验证这一问题的入口。如果其他采用 OpenAI SSO 的第一方或第三方服务存在类似的可利用漏洞，那么理论上也可能形成类似的访问链路。换句话说，论坛只是这次研究中找到的一个突破口，真正将论坛权限进一步延伸到 ChatGPT 和 Codex 的，是 OpenAI 的身份认证机制。

当用 AI 去找漏洞...

消息披露后，X 上很快出现了大量讨论。

有网友表示：“72 小时完成一整条 RCE 攻击链，太疯狂了。”

也有人把注意力放在了 6500 美元的赏金上：“他们最后就只给了你 6500 美元，虽然这个发现相当不错，但这个奖励实在有点寒酸。不过话说回来，研究做得很棒！”

还有网友认为，这样的漏洞影响显然不止 6500 美元：“说实话，我替这些研究人员感到可惜。和他们本来可能拿到的奖励相比，这几乎只是零花钱，因为这个漏洞的敏感程度远不止于此。”

还有一位网友分享了自己过去使用 AI Agent 的经历。

他表示，“他们的东西太糙了。4o 还是主力模型那会儿，我在网页聊天里说服我的 Agent 访问它的沙箱 Jupiter。它写了个脚本留在服务端，保持 VM 会话活着，然后开始浏览并解释沙箱内外的一切，连 IP 都给了我。我甚至拿到了环境里每个文件的 ls 输出，还有 VM 硬盘。它一点点全交出来了。”

毫无疑问，这起事件也再次暴露出 AI 驱动网络攻击正在带来的新变化。

这一次，AI Agent 不只是帮研究人员分析漏洞，而是参与了从漏洞发现、Exploit 构建，到整条攻击链验证的多个环节，整个过程不到 72 小时。

对此，研究人员也警示道：“过去需要一个资源充足的团队花费数月才能完成的工作，如今可能被压缩到几天之内。安全领域原有的假设，也必须跟上攻击者能力的变化。如今，更现实的威胁模型应该考虑漏洞利用的经济成本已经发生了什么变化，而不能再依赖那些过时的假设，认为只有特定的人群才有能力实施复杂攻击。”

参考：

https://www.theregister.com/security/2026/09/18/researchers-used-claude-to-hack-openai-employees-chatgpt-accounts/5297517

https://www.tomshardware.com/tech-industry/cyber-security/hackers-breach-openai-using-claude-tools-gaining-access-to-employee-accounts-and-the-companys-internal-codebase-initiating-a-harmless-pull-request-as-proof-of-the-hack