Codex が10年もののバグ2つを連鎖させ、HTTP/2 Bomb を組み上げました
6月2日、セキュリティ企業の Calif が HTTP/2 Bomb を公開しました。nginx、Apache httpd、Microsoft IIS、Envoy、Cloudflare Pingora の既定の HTTP/2 設定をそのまま落とせるリモート DoS 攻撃で、Shodan のスイープでは公開サーバー約88万台が射程に入っています。家庭用回線1本の攻撃者一人が、Envoy のメモリ32GBを約10秒で押さえ込み、Apache でも18秒で同じ状態にできます。これを実際に組み上げたのは OpenAI の AI コーディングエージェント Codex で、セキュリティ業界が10年近く別々に把握してきた2つの手法を連鎖させただけです。
連鎖の中身
どちらの手法も目新しいものではありません。HPACK は HTTP/2 のヘッダー圧縮方式で、RFC 7541 で定義されています。接続の両側が直近のヘッダーをためる小さな「ダイナミックテーブル」を持っていて、1バイトのインデックスでテーブル内の任意のヘッダーを参照できます。Cory Benfield が2016年に公開した「HPACK Bomb」(CVE-2016-6581)は、太いヘッダーを1つテーブルに突っ込み、それを何千回も参照させることでサーバーのメモリを吹き飛ばすものでした。各サーバーは対策として、デコード後のヘッダー総サイズに上限を設けるようになりました。
Calif の Bomb はその逆向きです。ほぼ空のヘッダーを1つテーブルに置き、それを指す1バイトの参照を数千個流します。デコード後のペイロードは小さいままなのでサイズ上限は発火しませんが、参照1つごとにサーバーの内部簿記で新しいエントリ割り当てが走ります。結果として、回線上の1バイトがサーバー側のメモリでは70バイトから4,000バイトに化けます。比率はサーバーによって違います。
次が「保持」のフェーズです。HTTP/2 では受信側がフローコントロール・ウィンドウを通告して、送信側が応答として何バイト送れるかを決めます。エクスプロイトはウィンドウを0バイトに通告してサーバーが応答を完了できないようにし、その上で数秒おきに1バイトの WINDOW_UPDATE フレームをぽつぽつ流して接続をタイムアウトさせません。Bomb が確保したバイトはすべてメモリに固定されたまま残ります。
Apache httpd と Envoy では、Cookie 処理がもう一段の増幅器として効きます。RFC 9113 §8.2.3 は、クライアントが Cookie ヘッダーを「クラム」(1つの name/value ペア)単位で分割して複数フィールドに分けて送ることを認めていますが、両サーバーともそのクラム数をヘッダー数の上限にカウントしていませんでした。Envoy はクラムを受け取るたびにバッファに継ぎ足し、Apache はクラムごとに統合済みクッキー文字列全体を再構築し、古いコピーをストリームが閉じるまで保持し続けます。実測の増幅率は 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つの対象すべてのソースコードを読み、2つの手法が合成できることに気づき、実際に動く連鎖をコードとして書き上げた、それだけです。Calif の記事の筆者は Thai Duong で、2012年の CRIME 攻撃で HTTP ヘッダー圧縮を破った当人であり、その代替案である HPACK のレビューも頼まれた人物です。公開記事の末尾で彼は当時の自分のレビューノートを読み返したと書いていて、この Bomb は一度たりとも考慮しなかったと認めています。
最近のバズの裏にある本当の話はこちらです。明確に警告が書かれていた2つの CVE 系統が同じ仕様の中に14年並んでいたのに、AI エージェントが現れるまで誰も組み合わせなかった、ということです。Calif は nginx と Apache の修正コミットが公開されてしまえば、まともなモデルなら diff からエクスプロイトを再構成できると指摘していて、実際に IIS、Envoy、Pingora の脆弱性を確認した経路もそれだった、と書いています。
パッチ状況はばらつきがあります。nginx は4月の時点で 1.29.8 に max_headers ディレクティブを投入済みです(既定上限は1,000)。Apache は5月27日の Calif の通知と同日に Stefan Eissing が同日付のコミットで修正し、CVE-2026-49975 が割り当てられました。パッチ自体は mod_http2 v2.0.41 に入っていますが、2.4.x 系の正式リリースにはまだ取り込まれていません。Envoy は6月3日からパッチを順次出していますが、検証はなお進行中です。Microsoft IIS と Cloudflare Pingora は記事公開時点でパッチなしで、Calif の推奨は HTTP/2 を切るか、リクエストごとのヘッダー数に固い上限をかける何かを前段に置くこと、です。
今後の注目ポイント
これから見るべきシグナルははっきりしています。Envoy の修正は検証を通過してタグ付きリリースに入る必要があります。Microsoft と Cloudflare の双方に公的な反応が求められます。Pingora は公開ウェブの相当部分のトラフィックを終端しているインフラなので、70:1 の増幅率でも規模が乗ると痛みます。今回の発見を主導した Quang Luong は今月後半にスタンフォードの Real World AI Security カンファレンスで手法を発表する予定で、Codex にどうプロンプトしたか、このワークフローがどの程度再現可能かが、そこでより明確になるはずです。さらに面白い試金石は次にあります。同じ種類のクロスコードベースなエージェント・レビューによる次の開示が、数週間以内に出るのか、それとも数ヶ月かかるのか、です。
出典