Claude，黑进了OpenAI

编辑｜Panda 天道好轮回，苍天饶过谁？入侵过 Hugging Face 和 Ruby 生态 的 OpenAI 原来也被入侵过！并且，入侵者使用的还是其主要竞对 Anthropic 的模型。 就在几个小时前，Electrovolt Security 与 Hacktron AI 创始人 s1r1us 在 𝕏 上发布了一系列推文，分享了其团队在 7 月份借助 Claude 成功入侵 OpenAI 的故事，引发广泛关注。 https://x.com/S1r1u5_/status/2100777801335095383 严格来说，这个故事并不算新。完整的技术复盘早在 9 月 13 日就挂在了 Hacktron 的博客上，并且标题颇有些挑衅意味：「 Ha cki ng OpenAI 」。 博客地址：https://www.hacktron.ai/blog/hacking-openai 真正让它在今天引爆的，是《华尔街日报》的独家报道《 黑 客 用 Anthropic 的 Claude 攻破 O pen AI 》，以及 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 都没有及时拿到这个安全 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 加上了沙箱隔离作为纵深防御。 Claude 在其中到底做了多少？ 这才是这条新闻真正的爆点。 Hacktron 的复盘写得相当坦白。他们先用 O pus 4.8 开了一个会话，把 Discourse 的 Docker 镜像丢给它，让它检查已安装的 libheif 包有没有安全问题，模型找出了那批没有被 backport 的修复。7 月 24 日，同样是 Opus 4.8 ，在关闭 ASLR 的条件下做出了一个可用的代码执行 exploit。但要在 Discourse 默认配置（ASLR 开启）下做到稳定，他们开了好几个会话都没成功。 当天晚上，Anthropic 发布了 Cl aud e 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