安全
OpenAI、Slack、Meta 和 GitHub 底下是同一个图像库。攻破它只花了模型三个小时
研究人员把 libheif 中的堆溢出,变成了在 OpenAI、Slack、Meta 和 GitHub Enterprise 上的远程代码执行。打补丁是容易的那部分;前沿模型只用三个小时就写出可用利用程序,才是防守方该读两遍的地方。
MAI
Hacktron 的三名研究人员整个夏天都在拉同一根线头:libheif,一个把 HEIC、HEIF 和 AVIF 文件解成像素的开源 C 语言库。本周,他们公布了这根线头牵出来的东西。该库解码路径上的一处堆缓冲区溢出,让他们在 OpenAI 的社区论坛上拿到远程代码执行,再由此进入 OpenAI 员工的 ChatGPT 与 Codex 账号,又由此进入这些账号所连接的 GitHub 仓库。同一类缺陷还波及 Slack、Meta、GitHub Enterprise Server、Discourse 和 Next.js。
这些都已修复。本文的重点并不是这个漏洞本身。
没人写进清单的依赖
几乎每一个接受用户上传照片的平台都必须解码图片,而几乎没有哪个平台自己解码。它们把字节交给一个原生库,对 HEIC 和 AVIF 而言,这个库通常就是 libheif,而真正的 HEVC 解码又交给 libde265。它不会出现在产品介绍页上,很少出现在威胁模型里,在大多数技术栈中,它是被某个图像处理组件或缩略图服务在第三、第四层之下顺带引入的。
上游公告 GHSA-g89c-p67h-r497 将其评为 9.8 分,并把触发条件写得很直白:一个构造过的 HEIC、HEIF 或 AVIF 文件,会在一次普通的解码调用中触发堆缓冲区溢出。不需要认证,不需要用户交互,也不需要特殊的 API 配置。任何解码不可信图片的应用都在受影响范围内。这份公告本身没有分配 CVE 编号——这提醒我们,"有 CVE"并不能代替"正在被跟踪"。
这也是为什么受影响名单读起来像现代互联网的通讯录,而不是某一家厂商的客户清单。
需要修复什么
| 组件 | 公告 | 修复版本 |
|---|---|---|
| libheif | GHSA-g89c-p67h-r497(CVSS 9.8) | 1.23.2 |
| libde265 | 上游公告 | 最新版本 |
| GitHub Enterprise Server | CVE-2026-19118 | 3.21.5 及以上 |
| Discourse | GHSA-vhm9-85gw-x335 | 最新版本 |
| Next.js | 2026 年 8 月安全版本 | 最新版本 |
| Meta 产品 | GHSA-2jg2-4ch7-h545 | 已在服务端修复 |
| OpenAI、Slack | 无公开公告 | 已在服务端修复 |
如果你自行部署了名单上的任何一项,要做的全部事情就是版本号。如果你运行着自己的图像处理流水线,那么要问的是:哪些服务在你不知情的情况下调用了 libheif,以及那次解码是发生在沙箱里,还是发生在应用进程内。
十四小时,与 6500 美元
研究人员报告中关于 OpenAI 的时间线异常具体。7 月 23 至 24 日,他们在 Discourse 可触达的那份 libheif 中定位到溢出。7 月 25 日上午,他们在 community.openai.com 上取得了代码执行。数小时内,他们通过 OpenAI 的 Bugcrowd 项目提交报告,随后接管员工账号、在 OpenAI 内部代码库中提交了一个拉取请求,以此证明影响范围。OpenAI 在同日 22:49 UTC 确认修复——距报告不到十四小时——并与 Discourse 上游协同处理,9 月 1 日支付了 6500 美元赏金。
这份响应是本次事件中运转良好的部分。论坛正是那种典型的"不起眼的相邻资产":因为没人把它当成生产环境,它反而积累了真实的访问权限。OpenAI 把它当作生产环境来对待。
真正要紧的是那三个小时
图像解析器中的内存破坏漏洞并不新鲜,模糊测试挖出这类缺陷已有二十年。过去限制它们的,是这样一个事实:找到崩溃很便宜,而把崩溃做成一个能稳定攻破现代加固目标的利用程序,则昂贵、稀缺、需要专门的功力。正因为存在这道鸿沟,这类漏洞大多被悄悄修掉,从未被武器化。
研究人员说,这道鸿沟已经消失。据他们描述,在标准内存保护开启的情况下,Claude Opus 4.8 在多次会话中都没能做出可用的利用程序;Opus 5 发布后数小时内,他们把同一个问题交给它,大约三小时便成功,随后研究人员把结果移植到目标所运行的架构上。他们的项目页面称,借助前沿模型的智能体式工作流,从初次探测到远程代码执行的利用开发周期被压缩到大约一到三天。
结论是他们自己下的:
AI 正在把这种稀缺的专业能力越来越多地转化为算力,从而拆掉这层保护。过去需要一支资源充足的团队和数月工夫才能完成的工作,如今可以压缩到几天。
这些是研究人员对自家工具的说法,应当照此阅读。但佐证并非修辞:七个平台完成修复、GitHub 分配了 CVE、赏金已经支付,以及因为报告附带了已验证的影响,补丁在不到一天内就落地。
防守方该带走什么
真正的实务教训完全不在于 AI,而在于:你那些未修复依赖的经济账变了。一个存在于你甚至不知道自己发布了的解析器中的内存安全漏洞,过去只是长长清单上的一项理论风险。"没人会费力去武器化它"这个前提,如今是这条推理中最脆弱的一环,也是大多数积压问题分级工作在默默依赖的前提。
把 libheif 升级到 1.23.2。然后弄清楚你的技术栈里还有什么在用 C 解析不可信字节,以及这件事是否发生在一个可以被隔离的地方。
信息来源: Hacktron: Hacking OpenAI · HEIF Heist · libheif 公告 GHSA-g89c-p67h-r497 · Forbes: Security Researchers Hacked Into OpenAI Using Anthropic's Claude