独立安全研究人员使用Anthropic的Claude入侵OpenAI

# 黑客OpenAI 来源：https://www.hacktron.ai/blog/hacking-openai 1. https://www.hacktron.ai/ 2. 博客 (https://www.hacktron.ai/blog) 3. 黑客OpenAI 利用堆溢出与SSO配置缺陷入侵OpenAI内部仓库 2026年9月13日 | 阅读时长11分钟 ## **引言** 2026年7月25日，我们通过组合两个关键漏洞成功入侵了多名OpenAI员工的ChatGPT账户。借助这些账户，我们得以访问OpenAI的内部代码仓库，并可能连接到更多其他系统。 为证实我们确实获得了预期权限（同时避免接触敏感信息），我们利用该员工的Codex账户在OpenAI内部单体仓库`openai/openai`中创建了PR #1186742。 **漏洞利用链** 1. **libheif** 图像解码器 2. **Debian** 缺失安全补丁 3. **ImageMagick** 调用libheif 4. **Discourse** 图像上传功能 5. **OpenAI论坛** community.openai.com 6. **OpenAI SSO** 身份验证缺陷 7. **ChatGPT / Codex** 账户访问权限 8. **GitHub** 关联集成 9. **内部仓库** OpenAI 截至两个月前，任何用户或OpenAI员工登录OpenAI官方帮助论坛（community.openai.com）时，其ChatGPT与Codex账户都可能被接管。由于用户可将多种服务接入Codex和ChatGPT，我们理论上可访问的范围极广，包括GitHub、Slack和电子邮件系统。 从初始发现到获得OpenAI仓库访问权限的全过程仅耗时不足72小时。 我们立即向OpenAI和Discourse报告了初始漏洞，并协同完成补丁部署。感谢他们严谨细致的态度与快速响应。OpenAI还为我们支付了**6500美元**漏洞赏金。 本文将完整披露漏洞发现过程。后续内容将详述如何发现两个漏洞、如何运用Claude模型，以及本次事件的启示。 ## **背景** 数月前，Hacktron团队（由Harsh Jaiswal领衔，成员包括Mohan Pedhapati和Rahul Maini）开始对前沿AI公司进行安全研究。这使我们发现了OpenAI身份基础设施中的SSO配置错误，以及OpenAI社区论坛中使用的**`libheif`**远程代码执行漏洞。 此后我们将研究扩展为[HEIF Heist（https://heif-heist.com/）](https://heif-heist.com/)计划，历时数月追踪**`libheif`**在Slack、Meta、GitHub Enterprise、Ruby on Rails及Node.js框架（如Next.js、Astro、Gatsby）中的影响范围。令人惊讶的是，[如此多](https://xkcd.com/2347/)常用软件依赖于这个图像处理库。  若您的应用处理用户上传的图像且支持.heic/.heif/.avif格式，则很可能受到影响。如需协助请通过[**[email protected]**](mailto:[email protected])联系我们。 > **补丁提示**：若自托管Discourse，请立即重建系统。旧版Docker镜像可能包含存在漏洞的`libheif`依赖，攻击者可通过图像上传执行代码。请在`/var/discourse`目录下执行`git pull`后运行`./launcher rebuild app`；仅更新Web界面可能无法替换底层镜像。Discourse托管用户已完成修补。详见[安全公告](https://github.com/discourse/discourse/security/advisories/GHSA-vhm9-85gw-x335)。 OpenAI使用Discourse搭建论坛，并通过`auth.openai.com`提供"使用OpenAI登录"功能。在充分了解OpenAI的服务与基础设施后，我们判断入侵论坛可能通过该身份验证流程渗透至更广泛的OpenAI服务。为验证该假设，我们首先需要在OpenAI服务（如Discourse社区论坛）上实现远程代码执行。 虽然Discourse应用本身并非易攻目标（我们曾研究过），但考虑其依赖项可能存在突破口。 ### **libheif堆缓冲区溢出** 7月23日，我们开始审查Discourse的图像上传流程，发现HEIC/HEIF文件的处理路径异常。Discourse通常使用FastImage进行图像校验，但由于FastImage不支持HEIF格式，便将文件交由ImageMagick的**`magick`命令**进行转换。这直接将底层**`libheif`解析器暴露给攻击者控制的文件**。 我们启动了一个Opus 4.8会话与Discourse Docker镜像交互，要求其检测已安装**`libheif`包**的安全问题。经过分析，发现某些安全修复未被反向移植到该软件包中。这导致HEIC解码过程中出现堆缓冲区溢出，进而获得越界读写原语。 值得注意的是，相关漏洞代码已于前一年在上游修改，但该提交未被标记为安全修复，也未获得CVE编号。这可能是Debian 12与13版本未能及时获得安全反向移植补丁的原因。由于Discourse的Docker镜像基于Debian 12，安装的是存在漏洞的**`libheif` 1.19.7版本**。当时Debian 13仍提供漏洞版本1.19.8。此后Debian于2026年8月8日发布了针对Debian 13的安全更新。 7月24日，我们利用Opus 4.8开发了可在禁用ASLR环境下运行的ImageMagick/**`libheif`代码执行漏洞利用程序**。随后启动多个独立会话，尝试使其在启用ASLR的Discourse默认配置中稳定运行，但未成功。 ### Opus 5发布 当日晚间，Anthropic发布了Claude Opus 5.5。我们启动新会话，在3小时内首先生成了适用于本地Mac的ARM64漏洞利用程序。接着要求其将漏洞利用移植到Discourse使用的x86-64环境及**`jemalloc`配置**。 截至7月25日凌晨6:00，我们已确认可通过图像上传实现本地远程代码执行。随后将Claude置于自主**`/goal`循环**中，针对我们自建的Discourse Cloud实例（通过**`rce.ee/ctf-forum`**代理模拟CTF目标，因Opus拒绝编写远程漏洞利用程序）进行攻击。 上午10:00检查时，该代理已在Discourse Cloud上实现远程代码执行，并通过读取**`/etc/hosts`**验证访问权限。利用生成的漏洞利用脚本，我们成功在OpenAI实例上执行代码。 确认无需交互即可接管论坛活跃成员ChatGPT/Codex账户的假设后，我们立即向OpenAI提交报告。随后接管了一名OpenAI员工账户，该员工的Codex账户已关联OpenAI的GitHub组织。为证明影响且不接触内部代码，我们向该员工的Codex账户发送指令，要求其在OpenAI内部单体仓库中为我们创建PR。此后立即停止所有测试。 > 脱敏后的Pull Request证明可访问OpenAI内部仓库 我们向BugCrowd提交了影响证据，并向OpenAI安全部门发出预警。同时准备报告提交给Discourse的HackerOne项目。Discourse在周六收到报告，周日回复，周一即完成修复（响应速度值得称赞）。他们[立即开始对ImageMagick进行沙箱隔离](https://github.com/discourse/discourse/commit/a07188016987de1613c961277e2e928aaa7c37ec)。 需要强调的是，此次权限提升漏洞并非Discourse特有。这是OpenAI SSO身份验证问题，使得论坛入侵可扩展至ChatGPT和Codex账户访问。任何使用OpenAI SSO的第一方或第三方服务被入侵时，都将导致相同后果——Discourse仅作为验证手段。 ## **漏洞发现成本** Discourse与OpenAI漏洞挖掘耗时数天（AI代理），人类参与时间仅数小时。整个[HEIF Heist（https://heif-heist.com/）](https://heif-heist.com/)研究项目针对Slack、Zoom、Meta等企业历时两个月，总Token消耗成本不足3000美元，由三名研究人员完成。适应新目标企业的漏洞利用通常仅需一至两天。 我们观察到每个新模型的能力都显著提升，本报告呈现的Discourse漏洞利用即是明证。Opus 4.8在多个会话中难以生成在ASLR启用环境下工作的漏洞利用程序。而Opus 5发布数小时后，我们向其提出相同问题即获解决。在整个攻击行动中，从Opus 5到GPT-5.6 Sol的能力跃升尤为明显——我们仅知目标存在漏洞，对系统本身一无所知。 每个目标测试都始于图像上传。在此基础上，我们通常无需确切了解**`libheif`版本、libc版本或部署环境**，即将内存破坏转化为可靠的内存泄露或Shell获取。AI几乎在完全陌生的情况下启动攻击，并在一两天内为各企业定制漏洞利用方案。除Shopify外，我们未发现其他企业检测到这些活动——即使发送了数千张图像导致其图像处理器反复崩溃。 当代码执行落入沙箱或受限环境时，模型还辅助了权限提升、横向移动和防御规避。这并非完全自主的黑客攻击，人类专业指导仍然关键，但小团队能完成的工作量呈指数级增长。 ## **结语** 软件长期受益于"复杂性安全"模式。代码甚至漏洞可能公开，但将错误转化为可靠漏洞利用仍需稀有专业知识、大量时间与目标环境知识。已知内存破坏漏洞的利用成本高昂，零日漏洞则主要保留给最高价值目标。 这从未构成真正的安全边界，但在实践中保护普通企业免受软件漏洞侵害。AI正通过将稀缺专业知识转化为计算能力来消除这层保护。过去需要资源充沛团队耗时数月的工作，如今可在数日内完成。 安全假设必须跟上攻击者能力。现实的威胁模型应考量当今漏洞利用的经济学基础，而非依赖[过时假设](https://www.hacktron.ai/blog/hacking-openai#ref-6)判断谁能实施复杂攻击。 Hacktron的使命是通过发现并消除广泛信任软件中的漏洞来保障互联网安全，防止恶意攻击者利用。我们正在前沿实验室及其他互联网关键系统中持续推进研究。若您负责相关系统安全，期待与您合作。 ## 受影响版本与补丁 [HEIF Heist（https://heif-heist.com/）](https://heif-heist.com/)不针对单一版本，而是瞄准多个发布系列（如1.19.x、1.20.x、1.22.x、1.23.x）中的生态系统漏洞。任何未部署最新上游安全补丁的系统均可能存在风险。 - **更新上游版本**：通过发行版安全渠道或上游发布安装最新的安全修补版**`libheif`**和**`libde265`**包。截至2026年9月14日，最新上游**`libheif`**安全版本为v1.23.4；v1.23.2已被后续安全修复取代。发行版软件包可能在旧上游版本号下包含反向移植修复，请同时查阅软件包安全公告。 - **纵深防御**：鉴于ISO基础媒体文件格式的复杂性和解码器更新速度，未来仍可能出现内存安全漏洞。生产架构应在无需处理HEIF/AVIF时禁用相关解码，或在加固的临时沙箱中隔离图像处理管道。ImageMagick的安全策略支持限制可接受格式和资源使用。 ## 致谢 感谢Sudanshu Rajhbhar的技术支持，以及Zayne Zhang、Fabian Faessler、Robert Chen和Jessica Ruan的校对、审稿与提升本文质量的宝贵反馈。 ## 参考文献 ## 与本研究团队合作 Hacktron汇聚顶尖CTF研究者、资深红队专家与进攻安全研究人员。我们运用AI加速安全研究，在广泛信任的软件中发现并消除漏洞，防止恶意攻击者利用。我们正在前沿实验室及其他互联网关键系统中持续推进研究。若您负责相关系统安全，期待与您合作。 [上一篇：OpenAI模型如何失控入侵Hugging Face](https://www.hacktron.ai/blog/here-is-how-openai-model-hacked-huggingface#post-title) 下一篇：您已是最新文章！(https://www.hacktron.ai/blog/hacking-openai#)