Codex 把两个十年老 Bug 串成了一枚可用的 HTTP/2 炸弹
6月2日,安全公司 Calif 披露了 HTTP/2 Bomb,一种针对 nginx、Apache httpd、Microsoft IIS、Envoy 和 Cloudflare Pingora 默认 HTTP/2 配置的远程拒绝服务漏洞,Shodan 扫描显示约有88万台公网服务器处在射程之内。一个用家用宽带的攻击者可以在约10秒内压住 Envoy 32GB 的内存,Apache 也只要18秒。把这条攻击实际拼出来的是 OpenAI 的 AI 编程代理 Codex,它把安全圈分别熟知近十年的两种技术连成了一条链。
攻击链
两半都不新鲜。HPACK 是 HTTP/2 的头部压缩方案,定义在 RFC 7541 里:连接两端各维护一张存放近期头部的小型"动态表",用1字节索引就能引用其中任何一项。Cory Benfield 2016年提出的"HPACK Bomb"(CVE-2016-6581)就是把一个大头部塞进表里,再引用几千次,把服务器内存撑爆。各服务器随后给出了对策:给解码后的头部总大小加上限。
Calif 的炸弹反过来玩。它在表里塞一个几乎为空的头部,然后丢出几千个指向它的1字节引用。解码后的负载本身很小,体积上限不会触发,但每一次引用都会在服务器内部簿记里触发一次新的条目分配。结果就是线缆上的1字节,在服务器内存里变成70到4000字节,具体倍数因服务器而异。
接着是"挂住"这一步。HTTP/2 让接收方通告一个流量控制窗口,告诉发送方响应可以发多少字节。漏洞利用通告一个零字节窗口,让服务器永远没法把回复发完,然后每隔几秒滴一个1字节的 WINDOW_UPDATE 帧,把连接的超时不断重置。炸弹分配出的每一字节都被牢牢钉在内存里。
Apache httpd 和 Envoy 还在 Cookie 处理上多吃了一层放大。RFC 9113 §8.2.3 允许客户端把 Cookie 头按"碎屑"(一对 name/value)拆成多个字段发送,而这两个服务器都没把这些碎屑算进头部字段数上限里。Envoy 每收到一个碎屑就往缓冲区里追加;Apache 则在每个碎屑到来时都重建合并后的整段 cookie 字符串,而且之前的副本一直存活到流关闭。实测放大比:Envoy 1.37.2 约5,700:1,Apache httpd 2.4.67 约4,000:1,nginx 1.29.7 约70:1,Windows Server 2025 上的 IIS 约68:1。
为什么重要
Codex 没有发明任何一半。它做的是:读完4个目标的源码,看出这两种手法可以叠加,然后把可用的连锁攻击写成代码。Calif 的文章作者是 Thai Duong——2012年用 CRIME 攻击击破 HTTP 头部压缩的本人,也是后来被请去 review HPACK 作为修复方案的人。他在披露文末尾说,自己重新翻了当年的 review 笔记,从没想到过这枚炸弹。
热闹之下真正的故事在这儿:两族公开的 CVE,清清楚楚地写在同一份规范里,被一前一后摆了14年,却没人把它们串起来,直到 AI 代理上场。Calif 在文中指出,nginx 和 Apache 的修复提交一旦公开,任何一个能用的模型都可以从 diff 反推出漏洞利用,他们也正是用这种方式确认了 IIS、Envoy、Pingora 同样受影响。
补丁进度并不一致。nginx 早在4月就把 max_headers 指令塞进了 1.29.8(默认上限1,000)。Apache 在5月27日 Calif 通报当天就由 Stefan Eissing 提交了同日的修复 commit,分配了 CVE-2026-49975 编号;补丁本身在 mod_http2 v2.0.41 里,但还没进 2.4.x 的正式发行。Envoy 从6月3日开始陆续推出修复,验证仍在进行。Microsoft IIS 与 Cloudflare Pingora 在文章发布时还没有补丁,Calif 给出的建议是关掉 HTTP/2,或者在前端放一个能对每个请求的头部数量强加硬上限的东西。
接下来值得关注的
接下来的信号都很具体。Envoy 的修复需要通过验证并落到带 tag 的正式版里。Microsoft 与 Cloudflare 都得给出公开回应——Pingora 终结着公网相当一部分流量,即便是70:1 的放大,放到那个量级也很疼。主导这次发现的 Quang Luong 计划在本月晚些时候去斯坦福的 Real World AI Security 大会演讲,届时会更清楚 Codex 是怎么被 prompt 的,以及整套工作流可重复到什么程度。更有意思的考验是下一步:同样用跨代码库代理 review 找出来的下一个披露,会在几周内出现,还是要等几个月。
信息来源