一张图片打进 OpenAI 内部代码库：Claude 助攻的 72 小时攻击链复盘

原创 威胁情报中心 2026-09-18 16:20 北京

Hacktron AI 针对 OpenAI 的授权安全研究：一张特制 HEIF 图片打穿 Discourse 社区论坛服务器，SSO 令牌横向进入员工 ChatGPT / Codex 账户上下文，最终借 GitHub 连接器触达内部 Monorepo——三层边界、完整时间线与防守启示全复盘。

2026 年 7 月，安全研究团队 Hacktron AI 在针对 OpenAI 的授权安全研究中，用一张特制 HEIF 图片打开了 OpenAI 社区论坛的服务器，又利用 OpenAI 单点登录体系中的令牌权限配置问题，进入多个员工的 ChatGPT / Codex 账户上下文，并借助其中一名员工的 GitHub 连接能力，最终触达 OpenAI 内部私有代码仓库 Monorepo。

这不是一次“AI 自己黑掉 OpenAI”的失控事件。更准确地说，这是一起由三名研究人员主导、AI 显著加速漏洞分析和利用开发的授权渗透测试。

但它仍然值得复盘。因为这条攻击链把三个原本分散的问题串在了一起：

1. 服务端图片解析组件暴露面过大：用户上传的 HEIF 文件最终被送进 ImageMagick 和 libheif 处理；
2. Linux 发行版安全回补滞后：上游 libheif 修复提交最初未被标记为安全修复，Debian 镜像中的旧版本因此缺少回补；
3. 统一身份认证的令牌信任范围过大：社区论坛侧获得的令牌可以横向访问 ChatGPT、Codex，并进一步借助 GitHub 连接器触达内部代码仓库。

01 事件卡片

02 72 小时：攻击链如何跨过三层边界

2.1 第一层边界：从图片上传到服务器 RCE

OpenAI 社区论坛运行在 Discourse 上。用户上传图片后，Discourse 会先做格式和尺寸检查。

问题在于，Discourse 使用的 FastImage 并不支持 HEIF / HEIC 格式。于是，当文件类型无法被 FastImage 正常识别时，处理流程会转向 ImageMagick 的 magick 工具；而 ImageMagick 对 HEIF 的支持又依赖系统里的 libheif 解码库。

这条链路可以简化为：

这里有几个关键技术点。

第一，攻击面来自“格式转换兜底路径”。
FastImage 无法识别 HEIF，并不意味着文件被拒绝；相反，文件进入了更复杂、也更危险的 ImageMagick / libheif 解析路径。对防守方来说，这类“兜底处理逻辑”往往比主流程更容易被遗忘。

第二，容器基础镜像里的 libheif 版本过旧。
Hacktron AI 发现，相关 Docker 镜像基于 Debian 12，系统内 libheif 为 1.19.7；当时 Debian 13 中的 1.19.8 也仍未包含相关修复。更麻烦的是，上游 libheif 的一些修复提交最初没有被明确标记为安全修复，也没有立即分配 CVE，因此发行版维护者没有及时回补。

第三，公开漏洞描述和实际利用效果需要区分。
CVE-2026-32882 / GHSA-hg7q-rjr2-8x46 的公开描述，是 libheif 在图像 overlay 合成逻辑中的越界读取问题，CWE 分类为 CWE-125，涉及 alpha 平面与颜色平面位深不一致时错误使用 stride 的索引问题。Discourse 安全公告 GHSA-vhm9-85gw-x335 则将其上游问题与“通过恶意 HEIF 文件实现 RCE”的风险关联起来。

因此，准确的说法不是“公开 PoC 已经证明该 CVE 在所有环境下都可直接 RCE”，而是：

2.2 第二层边界：从论坛服务器到员工 ChatGPT / Codex 账户

拿下 Discourse 服务器本身，还不是这次事件最严重的地方。

真正改变影响范围的，是研究人员随后在服务器环境中发现了可用于 OpenAI 统一身份认证体系的身份令牌。部分令牌并不只服务于社区论坛，还可以被用于访问 ChatGPT 和 Codex。

换言之，攻击链在这里完成了一次关键跳跃：

这类问题的核心不是“SSO 本身有漏洞”，而是令牌作用域和权限边界配置不当。统一登录体系本应降低身份管理复杂度，但如果低安全等级的外围服务与核心产品共享过宽的令牌信任关系，任何一个外围系统失陷，都可能变成核心账户失陷。

Hacktron AI 在报告中特别强调，第二阶段的权限提升问题位于 OpenAI 侧，而不是 Discourse 产品本身。即使不是 Discourse，任何接入同一 SSO、且能保存或接触到相关令牌的第三方服务失陷，都可能造成类似后果。

2.3 第三层边界：从 Codex 到内部 Monorepo

研究人员进一步发现，其中一名 OpenAI 员工的 Codex 环境连接了 OpenAI 的 GitHub 组织。

于是，攻击链继续延伸到研发协作边界：

Hacktron AI 最终在 OpenAI 内部 Monorepo 中创建了一个 Pull Request，编号为 #1186742，PR 文本包含 “Hacktron AI Team PoC” 以及研究人员的公开社交账号链接。该 PR 没有被合并，研究人员也表示没有继续浏览敏感源代码。

《华尔街日报》援引知情人士称，Monorepo 中包含 OpenAI 的专有软件和算法代码，例如提升模型运行效率、优化系统性能的实现代码，但不包括模型权重。OpenAI 对 GitHub 活动日志的复核结论是，研究人员对相关私有仓库元数据和代码变更存在“有限读取”，但未发现进一步滥用。

因此，这起事件不能被夸大为“OpenAI 核心模型权重泄露”。更准确的边界是：研究人员证明了从外围论坛到内部代码仓库的可达性，并在进入敏感区域后主动停止。

03 完整时间线

以下时间以公开报告为准，UTC 时间为主。

04 Claude 在其中到底做了什么

这起事件最容易被误读成“AI 自主入侵 OpenAI”。公开事实并不支持这个结论。

4.1 Opus 4.8 能发现漏洞，但卡在 ASLR

研究人员首先使用 Claude Opus 4.8 分析 libheif 代码和 Debian 补丁状态。模型帮助他们定位了上游修复未被回补的问题，并构造出在关闭 ASLR 的环境下可用的利用代码。

但在真实目标开启 ASLR 后，该利用代码失败。

这说明当时的模型已经具备较强的代码审计、补丁差异分析和利用原型开发能力，但在复杂内存布局、地址随机化和堆分配器行为面前，仍然需要更强的推理和调试能力。

4.2 Opus 5 把利用开发推进到可用状态

7 月 24 日晚，Anthropic 发布 Claude Opus 5。研究人员改用新模型后，约 3 小时完成了 ARM64 环境下的利用代码，随后又将其移植到 x86-64 和 jemalloc 环境。

这里最值得关注的不是“3 小时”这个数字本身，而是模型完成的任务类型发生了变化：它不只是解释漏洞原理，而是在复杂约束下迭代出可运行的 exploit。

这相当于把过去高度依赖少数二进制安全专家的能力，部分压缩成了一次可重复调用的模型工作流。

4.3 研究人员仍需要“引导”和“包装”测试过程

Hacktron AI 报告还提到，为了让模型在授权测试边界内持续工作，他们使用了一个本地 /goal 循环，并通过研究人员控制的 rce.ee/ctf-forum 代理，将自己的 Discourse Cloud 测试目标呈现为类似 CTF 的授权环境。

这个细节有两层含义：

• 一方面，模型在面对远程漏洞利用请求时仍存在安全限制，并不是无条件输出攻击代码；
• 另一方面，只要攻击者能够控制上下文包装和目标环境描述，模型护栏就可能被引导到“安全测试”语境中。

这不是传统意义上的“模型越狱成功”，但它说明：面向安全研究的模型能力越强，对授权证明、目标验证和使用审计的要求就越高。

4.4 成本正在快速下降

Hacktron AI 披露，OpenAI 这部分研究只消耗了“数天的 agent 工作时间和数小时的人工时间”。其更大的 HEIF Heist 研究持续约两个月，涉及 Slack、Meta、GitHub Enterprise、Ruby on Rails、Next.js、Astro、Gatsby 等多个目标，总模型调用成本不到 3000 美元，团队只有三名研究人员。

这组数字的意义不在于证明“任何人都能低成本入侵大厂”，而在于说明：漏洞研究和 exploit 开发的边际成本正在明显下降。

05 为什么 6500 美元赏金反而值得注意

很多人看到“进入 OpenAI 内部代码库，只奖励 6500 美元”会觉得金额偏低。但公开信息里有一个重要细节：

OpenAI 认为 Discourse 目标本身不在其漏洞赏金范围内，因此并没有为“打穿 Discourse”这一入口支付赏金；6500 美元奖励的是研究人员发现并证明了 OpenAI 侧身份权限配置问题。

这也解释了为什么 Hacktron AI 要同时向两个方向披露：

• Discourse 图片处理问题：通过 HackerOne 报告给 Discourse；
• OpenAI SSO / 令牌权限问题：通过 Bugcrowd 报告给 OpenAI。

从防守角度看，这恰恰说明漏洞赏金范围和实际风险边界并不总是一致。企业可能把某个第三方社区系统列为“范围外”，但如果该系统保存了可访问核心服务的令牌，它仍然可能成为进入核心资产的路径。

06 影响边界：哪些事情发生了，哪些没有发生

这起事件最严重的地方，不是已经造成了多大的数据损失，而是它证明了一条低成本、可复用的权限放大路径确实存在。

07 对企业的四点启示

7.1 把图片处理链当作高危攻击面管理

图片解析库长期是内存安全漏洞高发区。企业不应只检查应用框架版本，还要完整梳理：

• 哪些上传格式会进入 ImageMagick、libheif、libde265、libvips、FFmpeg 等组件；
• 哪些“不支持格式”会触发兜底转换；
• 容器基础镜像中的系统库版本是多少；
• 是否只依赖 CVE 订阅，而忽略上游“未标记为安全修复”的提交。

对不必要的 HEIF / AVIF 解码能力，应直接关闭或限制。

7.2 图片处理必须运行在低权限、无秘密、短生命周期环境中

图片转码和缩略图服务应尽量满足：

• 独立容器或独立沙箱；
• 非 root 运行；
• 禁止或严格限制出站网络；
• 不挂载业务数据库、对象存储凭据和 SSO 密钥；
• 文件处理完成后销毁临时环境；
• 对 ImageMagick 配置严格 policy，只开放必要格式和委托器。

Discourse 在修复中增加 ImageMagick 沙箱，正是这一思路。

7.3 SSO 要做“统一认证”，不能做“统一放权”

外围论坛、支持系统、文档系统、社区平台与核心产品之间，应明确区分令牌受众和权限范围。

建议重点检查：

• 外围服务签发的 token 是否能访问核心产品；
• ChatGPT / Codex / GitHub 等高权限服务是否要求独立授权；
• token 是否绑定 audience、scope、设备、IP 风险级别和有效期；
• 第三方服务失陷后，能否一键撤销其关联会话；
• GitHub、Slack、邮件等连接器是否采用最小权限。

统一身份认证的目标应是“统一证明你是谁”，而不是“一次登录后处处默认可信”。

7.4 面向 AI Agent 的连接器要按“新员工权限”治理

Codex、Claude Code、内部 Copilot、CI Agent 等工具连接 GitHub、Slack、邮件和云环境后，本质上已经具备了“数字员工”的行为能力。

因此，企业需要像管理新员工一样管理它们：

• 默认只读，写权限按需开通；
• 对 PR、合并、发布、删除等高风险操作设置人工确认；
• 对异常时间、异常仓库、异常设备发起的 Agent 操作进行告警；
• 对连接器令牌单独轮换，不与用户长期会话绑定；
• 明确 AI Agent 可触达的数据边界和禁止动作。

08 技术附录

8.1 基本信息表

8.2 攻击链映射

8.3 MITRE ATT&CK 技术映射

8.4 CVE / CWE / 组件关系

8.5 失陷指标与事件痕迹

截至目前，公开报告没有披露可用于全网封禁的传统恶意 IOC，例如恶意文件哈希、攻击者 IP、C2 域名或恶意样本下载地址。以下内容是事件痕迹和检测线索，不应被直接当作恶意基础设施名单。

8.6 可操作的检测建议

图片处理链检测

• 监控 magick、ImageMagick 子进程、libheif 相关进程的异常崩溃、频繁重启和 core dump；
• 对短时间内大量 HEIF / HEIC 上传、异常尺寸、异常位深、异常 alpha 通道组合进行限速和沙箱复核；
• 检查容器镜像中是否仍存在 Debian 12 + libheif 1.19.7、Debian 13 + libheif 1.19.8 等旧组件组合；
• 检查 ImageMagick policy 是否开放了不必要的 HEIF / AVIF / 委托解码能力；
• 告警图片处理容器发起出站连接、读取环境变量密钥、访问 metadata 服务等异常行为。

身份与令牌检测

• 检测 Community / 论坛类低权限服务的令牌被用于 ChatGPT、Codex、GitHub 等高权限服务；
• 建立 token audience、scope、签发方、使用方之间的异常匹配规则；
• 对同一令牌跨多个产品、多个设备、多个网络环境使用进行告警；
• 对 GitHub 连接器在非工作时间、异常设备、异常仓库上创建 PR 的行为进行重点审计；
• 在第三方服务失陷后，联动撤销其相关用户的全部活跃会话、OAuth 授权和连接器令牌。

补丁验证

09 结语

这起事件没有演变成真实数据泄露，也不存在模型权重失守。但它仍然是一次很有价值的安全预警。

过去，企业通常把“外围社区系统漏洞”和“核心研发资产”分开评估；把“系统库补丁滞后”和“身份权限配置”分开评估；把“AI 辅助安全研究”和“真实攻击链”分开评估。

Hacktron AI 的这次研究证明，攻击者不会按照企业的资产分类表行动。

一张图片可以进入图片解码库；一个解码库可以进入服务器；一个服务器可以暴露令牌；一个令牌可以进入员工账户；一个员工账户可以通过连接器触达代码仓库。每一环单独看都不一定能造成灾难，但串起来，就是一条从互联网边缘到研发核心的完整路径。

对防守方来说，真正需要补齐的不是某一个 CVE，而是三件事：

1. 高危解析组件的供应链可见性；
2. 跨服务令牌的权限隔离和快速撤销能力；
3. AI Agent 连接器的最小权限与行为审计。

当 AI 把 exploit 开发周期压缩到小时级，留给防守方的窗口也会同步缩短。未来安全团队面对的，可能不是“有没有漏洞”，而是“能不能在攻击者调用 AI 之前，先让 AI 帮自己把这条链路找出来”。

10 参考链接

1. Hacktron AI：Hacking OpenAI
https://www.hacktron.ai/blog/hacking-openai

2. The Wall Street Journal：Hackers Used Anthropic's Claude to Break Into OpenAI
https://www.wsj.com/tech/ai/hackers-used-anthropics-claude-to-break-into-openai-b40ba883

3. Discourse 安全公告：GHSA-vhm9-85gw-x335
https://github.com/discourse/discourse/security/advisories/GHSA-vhm9-85gw-x335

4. libheif 安全公告：GHSA-hg7q-rjr2-8x46
https://github.com/strukturag/libheif/security/advisories/GHSA-hg7q-rjr2-8x46

5. NVD：CVE-2026-32882
https://nvd.nist.gov/vuln/detail/CVE-2026-32882

6. Debian Security Advisory：DSA-6417-1 libheif
https://lists.debian.org/debian-security-announce/2026/msg00328.html

7. libheif v1.23.4 Release
https://github.com/strukturag/libheif/releases/tag/v1.23.4

8. Anthropic：Claude Opus 5
https://www.anthropic.com/news/claude-opus-5

9. OpenAI Bug Bounty Program
https://openai.com/index/bug-bounty-program/

10. Bugcrowd：OpenAI Bug Bounty
https://bugcrowd.com/engagements/openai

11. 云头条 / 网易号：Claude 侵入 OpenAI：内部代码权限被拿下
https://www.163.com/dy/article/L73T8KII0511D6RL.html

阅读原文

跳转微信打开