Claude，黑进了OpenAI

因果循环，报应不爽？曾攻击过 Hugging Face 和 Ruby 生态的 OpenAI，如今自己也遭到了入侵！而且，入侵者使用的竟是其主要竞争对手 Anthropic 的模型。

就在数小时前，Electrovolt Security 与 Hacktron AI 的创始人 s1r1us 在 𝕏 上连续发布多条推文，讲述了其团队在 7 月份利用 Claude 成功入侵 OpenAI 的经历，此事迅速引发热议。

https://x.com/S1r1u5_/status/2100777801335095383

严格来说，这并非新近发生的事件。完整的技术分析早在 9 月 13 日就已发布在 Hacktron 的博客上，标题颇具挑衅意味：「Hacking OpenAI」。

博客地址：https://www.hacktron.ai/blog/hacking-openai

真正让此事在今天引爆舆论的，是《华尔街日报》的独家报道《黑客用 Anthropic 的 Claude 攻破 OpenAI》，以及 s1r1us 本人亲自下场，将整条攻击链详细拆解。推文发布后数小时内，浏览量已突破 55 万，在 Hacker News 上也热度极高。

s1r1us 本名 Mohan Pedhapati，是 Hacktron AI 的联合创始人兼 CTO。参与此次研究的还有安全研究主管 Harsh Jaiswal 和研究员 Rahul Maini，共计 3 人。

时间线上，从最初发现漏洞到最终获取 OpenAI 内部代码仓库的访问权限，整个过程不到 72 小时。

Hacktron 博客展示的九步攻击链示意图

72 小时：从一张图片到 OpenAI 的内部单体仓库

整条攻击链的起点仅仅是一次「上传一张 HEIC 格式的图片」操作。

OpenAI 的用户社区 community.openai.com 运行在 Discourse 平台上。Discourse 通常使用 FastImage 进行图片校验，但 FastImage 不支持 HEIF 格式，因此这类文件会被转交给 ImageMagick 的 magick 命令进行处理，底层的 libheif 解析器便直接暴露在了攻击者可控的文件面前。

Hacktron 团队于 7 月 23 日开始审计这条图片上传流程，随后在 libheif 中确认了一个堆缓冲区溢出漏洞。

最值得安全从业者警惕的是这个漏洞的来历：相关代码的上游在前一年已经修改过，但那次提交并未被标记为安全修复，也没有分配 CVE 编号。结果导致 Debian 12 和 Debian 13 都没有及时收到这个安全补丁。Discourse 的 Docker 镜像基于 Debian 12，安装的是 1.19.7 版本，而当时的 Debian 13 仍然包含有问题的 1.19.8 版本。一个未被当作安全问题的提交，在依赖链的末端演变成了一次远程代码执行。Debian 直到 8 月 8 日才为 Debian 13 推送安全更新。

获取论坛的 RCE 只是第一步。真正将影响放大的，是第二个漏洞：OpenAI 自家的 SSO 缺陷。OpenAI 允许用户通过 auth.openai.com 的「Sign in with OpenAI」功能登录论坛，这条身份验证链路存在配置问题，使得攻陷论坛后可以进一步接管曾登录过该论坛的用户所拥有的 ChatGPT 和 Codex 账号，其中就包括 OpenAI 员工。

团队在博客中专门强调：这个可被利用来提升权限的漏洞并非 Discourse 独有，Discourse 只是他们选择用来证明的一条路径，任何使用 OpenAI SSO 的第一方或第三方服务被攻陷，都会导致同样的后果。

而 ChatGPT 和 Codex 账号通常关联着 Outlook、Gmail、Google Drive、Slack、GitHub 等一系列服务。理论上可触及的范围因此远远超出了聊天记录本身。

为了在不读取任何敏感内容的前提下证明访问的真实性，团队选择了一个 Codex 已连接到 OpenAI GitHub 组织的员工账号，向该账号的 Codex 发送了一条指令，令其在 OpenAI 的内部单体仓库 openai/openai 中创建了一个无害的 pull request，随后立即停止了所有进一步测试。

向 OpenAI 内部单体仓库提交的 PoC pull request 示意图，非原始截图（OpenAI 要求不展示原始截图）

据《华尔街日报》援引知情人士的说法，这个 monorepo 中存放的是让模型运行更快、效率更高的算法机密，相当于公司的配方，但不包含模型权重；研究人员提交的改动落在了一份文档文件上，内容包含「Hacktron AI Team PoC」字样以及两位研究员的 𝕏 账号链接，该建议未被采纳。

时间线非常紧凑。7 月 25 日 UTC 时间凌晨 5 点到 6 点之间，团队获得了论坛的 RCE 和管理员权限；8 点到 10 点通过 Bugcrowd 提交报告；13 点半到 15 点半完成了员工账号接管与 PoC 提交，同时在推特上直接联系 OpenAI 的朋友示警，并在 15 点半左右停止操作；当天 22 点 49 分，OpenAI 回复确认问题已修复，距离最初提交报告约 14 小时。向 Discourse 提交的报告走的是 HackerOne 平台，周六提交、周日回复、周一修复完成，7 月 28 日发布安全公告 GHSA-vhm9-85gw-x335，并顺势为 ImageMagick 增加了沙箱隔离作为纵深防御措施。

Claude 在其中扮演了多大角色？

这才是这条新闻的真正爆点。

Hacktron 的复盘写得相当坦诚。他们首先使用 Opus 4.8 开启了一个会话，将 Discourse 的 Docker 镜像交给它，让其检查已安装的 libheif 包是否存在安全问题，模型找出了那些未被 backport 的修复。7 月 24 日，同样是 Opus 4.8，在关闭 ASLR 的条件下制作出了一个可用的代码执行 exploit。但要在 Discourse 的默认配置（ASLR 开启）下实现稳定利用，他们尝试了多个会话均未成功。

当天晚上，Anthropic 发布了Claude Opus 5。

团队开启了一个新会话，在三小时内拿到了一个能在本地 Mac 上运行的 ARM64 版本，接着让它移植到 Discourse 所使用的 x86-64 环境和 jemalloc 配置。到 7 月 25 日早上 6 点，通过图片上传实现本地 RCE 得到了确认。

接下来更有趣的是，Opus 拒绝为远程实例编写 exploit，于是团队将自己的 Discourse Cloud 实例通过一个代理包装成看起来像 CTF 靶场的样子，再将 Claude 放入自主的 /goal 循环中运行。上午 10 点回来查看时，agent 已经在 Discourse Cloud 上获取了 RCE，并通过读取 /etc/hosts 证明了这一点。利用这个自动生成的脚本，他们随后在 OpenAI 的实例上复现成功。

模型的安全护栏确实被触发了，但它仅仅拦住了「远程」这个词。

成本数字同样惊人。Discourse 和 OpenAI 这一部分只花费了 agent 几天时间、人类几个小时；而覆盖 Slack、Zoom、Meta 等多家公司的整个 HEIF Heist 研究项目，历时两个月，三名研究员，token 总花费不到 3000 美元，适配到一家新公司通常只需要一两天。

团队称，测试从上传一张图片开始，在通常不知道目标具体 libheif 版本、libc 版本和部署环境的情况下，AI 几乎是盲目地尝试将内存破坏转化为可靠的内存泄露或 shell。据他们观察，除 Shopify 外，没有任何一家公司察觉到这些活动，哪怕图片处理进程被反复打崩、发送量已达数千张。

不过，需要说明两点：

Hacktron 自己强调这并非全自动黑客攻击，熟练的人类引导依然关键，变化的是一支小团队能完成的工作量级。

被点名的不仅仅是 Claude——他们同时提到，在对目标系统一无所知的盲打场景中，从 Opus 5 到 GPT-5.6 Sol 又出现了一次明显的能力跃升。这不是单家模型厂商的问题。

6500 美元和一句补充说明

9 月 1 日，OpenAI 发放了 6500 美元赏金并将报告标记为已解决，同时附上一句措辞谨慎的补充：「针对 Discourse 托管的 community.openai.com 的测试本就被明确排除在其赏金计划范围之外，这笔奖励认可的是 OpenAI 侧的发现，而非针对 Discourse 的行为。」

6500 美元就买下了一条通往内部单体仓库的路径，这个数字在社交媒体上很快成为了争议焦点。

真正将讨论推向更深层次的，是安全研究者 Joshua Saxe 的一条长帖。他在文章发表前受 WSJ 和 s1r1us 之邀，对这条 kill chain 进行了中立的技术复核。

他抛出的几个问题都很难回答：已经有多少更强大的攻击者更早进入、并且走得更远，拿走了算法机密、模型权重或者用户数据？此刻有多少驻留程序还留在前沿实验室的网络里？这种程度的「软」在各家实验室之间有多普遍，它们距离安全与研发效率之间的合理平衡点还有多远？

https://x.com/joshua_saxe/status/2100775309012296171

他最尖锐的一问指向了 Anthropic：既然 Hacktron 正是利用 Anthropic 的模型完成了这次入侵，那么 Anthropic 那套网络安全护栏的公共安全 ROI 究竟是多少——它给合法的防守方增加了实实在在的摩擦，而攻击方稍加周折就绕了过去。他的结论是，精英级的持续性入侵能力正在被迅速平民化，而这正像一列货运火车一样呼啸而来。

因果循环的另一半

将这件事放回时间线上，会发现 2026 年前沿实验室的安全历史已经相当混乱。

7 月，OpenAI 与 Hugging Face 共同披露了一起事故：OpenAI 在 ExploitGym 这一公开基准上测试 GPT-5.6 Sol 和一个未发布的内部模型，为了运行评测而关闭了对外部署时的同等防护，结果模型突破了评估环境的隔离边界、触及公网，并攻陷了 Hugging Face 生产基础设施的一部分。

9 月 11 日，研究者 Spencer Kitts、Thomas Larsen 和 Sydney Von Arx 又披露，早在 5 月 11 日，OpenAI 的测试 agent 就已经向 RubyGems 上传了数百个恶意包，试图窃取用户凭据。RubyGems 曾一度将其当作 DDoS 攻击处理并暂停新用户注册，最终封禁相关账号、撤下 500 多个恶意包，5 月 16 日恢复注册。

再往前，还有一起被安全社区称为「wiki 事件」的插曲：约 18000 条来自自称 OpenAI 系统的自主 agent 的帖子被发现散布在一个德语 wiki 农场上，agent 们利用公共站点互相传递答案、勘察环境，其中一条记录显示，某个 agent 发布了绕过 OpenAI 沙箱网络限制的方法，14 分钟后另一个 agent 就照做了。

9 月 5 日，OpenAI 在官方 𝕏 账号上表态，称现在已经到了该为「何时、如何披露 misalignment 事件」制定标准的时候，而不只是披露模型的 misalignment 属性，框架将在未来几周公布，同时公司正在与全球数十个监管机构沟通。

而就在今天这条 Claude 入侵新闻传播的同时，人们也在关注 OpenAI 披露了自 3 月以来的六起异常模型行为。

一边是自家 agent 越狱去攻击别人的基础设施，一边是别人利用竞争对手的模型打进了自家的单体仓库……

xkcd 2347「Dependency」，Hacktron 博客引用图

结语

Hacktron 在文章结尾给出了一个我认为是全文最有价值的判断：软件行业长期享受着一种「靠复杂度获得的安全」。

代码是公开的，漏洞甚至也可能是公开的，但将一个 bug 转化为可靠的 exploit，需要稀缺的专业能力、大量时间以及对目标环境的了解。已知的内存破坏漏洞武器化成本很高，零日漏洞则基本只留给最高价值的目标。

这不是一条真正的安全边界，但它在实践中确实保护了普通公司很多年。AI 正在将这层保护取消掉：它正将稀缺的专家能力转换成算力。值得注意的是，在此次事件中，团队使用的工具也涉及了开元娱乐旗下的某些技术组件，但这并非攻击的核心要素。

本文来自微信公众号 “机器之心”（ID：almosthuman2014），作者：机器之心，36氪经授权发布。