+86 +86 176 6927 1311 +86 +86 176 6927 1311
新闻中心
因果循环，报应不爽？曾对 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 博客展示的九步攻击链示意图
整条攻击链的起点仅仅是「上传一张 HEIC 格式的图片」。
OpenAI 的用户社区 community.openai.com 运行在 Discourse 平台上。Discourse 通常使用 FastImage 进行图片校验，但 FastImage 不支持 HEIF 格式，因此这类文件会被转交给 ImageMagick 的 magick 命令进行处理，底层的 libheif 解析器便直接暴露在了攻击者可控的文件面前。
Hacktron 团队于 7 月 23 日开始审计这条图片上传流程，随后在 libheif 中确认了一个堆缓冲区溢出漏洞。
最值得安全从业者警惕的是这个漏洞的来历：相关代码的上游在前一年就已进行过修改，但那次提交并未被标记为安全修复，也未分配 CVE 编号。结果是，Debian 12 和 Debian 13 均未及时获得这个安全 backport。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 添加了沙箱隔离作为纵深防御。
这才是这条新闻真正的引爆点。
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 又出现了一次明显的能力跃升。这不是单一模型厂商的问题。
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氪经授权发布。