OpenAI Codexが「HTTP/2爆弾」を発見-1台のPCからDOS攻撃が可能に(CVE-2026-49975)|セキュリティとAIのニュース-セキュリティ対策Lab

投稿日時: 2026年06月09日更新日時: 2026年06月09日

2026年6月2日、攻撃的セキュリティ企業Calif（Quang Luong研究員）は、HTTP/2に対するリモートサービス妨害（DoS）攻撃手法「HTTP/2 Bomb」を公式ブログで公開しました。

最大のリスクは攻撃のコスト効率にあります。100Mbpsの家庭用インターネット接続を持つ1台のPCから、特別なボットネットや大量のトラフィックを必要とせず、nginxサーバーのRAM 32GBを約45秒で枯渇させ、Apache HTTPサーバーのRAM 32GBを約18秒で、Envoyのそれを約10秒で使い果たすことができます。

Microsoft IIS（Windows Server 2025）は64GBのRAMを約45秒で消費させることが確認されています。さらに重要な事実は、この攻撃の発見者が人間の研究者ではなくOpenAI Codex（AIコーディングエージェント）であるという点です。

Califの研究者によれば、攻撃を構成する2つの手法（HPACKヘッダー圧縮の悪用とHTTP/2フロー制御ストール）はそれぞれ単独では10年前から知られていましたが、それを組み合わせて主要5サーバーに対して実際に機能する攻撃として構築したのはCodexが初めてです。

パッチはnginx 1.29.8とApache mod_http2 2.0.41（CVE-2026-49975）では提供済みですが、Microsoft IIS・Envoy・Cloudflare Pingoraは記事執筆時点でパッチが未提供であり、即時の緩和措置が求められます。本記事では攻撃の仕組み・影響を受けるサーバーとバージョン・Shodanが示す880,000超の露出サイト数・修正バージョンと緩和策を詳細に解説します。

サマリー

2026年6月2日、Calif（研究者：Quang Luong）が「HTTP/2 Bomb」を公開。OpenAI Codexが発見した組み合わせ攻撃
影響サーバー：nginx・Apache httpd・Microsoft IIS・Envoy・Cloudflare Pingora（デフォルトHTTP/2設定）
1台100Mbps接続のPCから最短10秒（Envoy）〜45秒（nginx・IIS）でRAMを枯渇させてサーバーをクラッシュ
増幅比：Envoy 約5,700:1・Apache 約4,000:1・nginx 約70:1・IIS 約68:1（1バイト送信が数千〜数万バイトのRAM確保を引き起こす）
Shodan調査：HTTP/2対応の5サーバーを運用するウェブサイトが880,000件以上（多数がCDN背後だが直接露出分は攻撃対象）
2つの既知手法の組み合わせ：①HPACKインデックス参照ボム（ヘッダーエントリごとのブックキーピングを悪用・デコードサイズ制限をバイパス）＋②HTTP/2 Window Stall（ゼロバイトフロー制御ウィンドウでメモリを無限に保持）
PoC（概念実証スクリプト）がGitHub上で公開済み
パッチ提供状況：nginx 1.29.8✅・Apache mod_http2 2.0.41（CVE-2026-49975）✅・Envoy（6/3パッチ公開、検証中）⚠️・Microsoft IIS未提供❌・Cloudflare Pingora未提供❌
即時緩和策：未パッチサーバーはHTTP/2無効化またはリバースプロキシ/WAFで厳格なヘッダーカウント制限を追加
RFC 7541の仕様レベルの根本的欠陥であるという分析——5つの独立した実装が同クラスのバグを持つ事実が示す

1 HTTP/2 Bomb の技術的な仕組み—2つの既知手法の危険な組み合わせ
- 1.1 ①HPACKインデックス参照ボム——デコードサイズ制限をバイパスする新変種
- 1.2 ②HTTP/2 Window Stall——メモリを解放させないSlowloris型ホールド
2 テスト結果-1台のPCが何秒でサーバーを落とすか
3 OpenAI Codexが発見
4 RFC仕様レベルの欠陥という分析
5 影響範囲—Shodanで確認できる880,000超のサイト
6 開示タイムラインとパッチ提供状況
7 緩和策と修正バージョン——サーバー別の即時対応
8 FAQ
9 参考情報

HTTP/2 Bomb の技術的な仕組み—2つの既知手法の危険な組み合わせ

詳述する攻撃の核心は、以下の2つの手法の組み合わせです。

①HPACKインデックス参照ボム——デコードサイズ制限をバイパスする新変種

HTTP/2の標準であるHPACK（RFC 7541）はHTTPヘッダーの圧縮スキームです。接続の両側が「ダイナミックテーブル」と呼ばれる最近見たヘッダーのキャッシュを保持します。送信者は最初にヘッダーをテーブルに挿入し、以降は1バイト程度の「インデックス参照」で同じヘッダーを再利用できます。受信者（サーバー）はそのインデックスを参照し、ヘッダーの完全なコピーをRAMに確保します。

2016年に発見された古典的な「HPACKボム」（CVE-2016-6581）は、大きな値をテーブルに詰め込む手法でしたが、各サーバーは「デコードされるヘッダーの合計サイズの上限」という制限を実装してこれを無効化しました。

今回の新変種はその制限を巧みに回避します。ヘッダーの値はほぼ空にしておき、増幅はデコードサイズではなく**サーバーが各ヘッダーエントリ周辺に確保するブックキーピング用のRAM（ヘッダーエントリごとの内部管理データ）**から生じます。デコードサイズ制限はほぼ何もデコードするものがないため発動しません。

Cookieヘッダーを使ったバイパス手法：Apache・Envoyのようにヘッダーフィールドの「件数」に上限を設けているサーバーに対しては、RFC 9113 §8.2.3がCookieヘッダーを1フィールドごとに分割して送信することを明示的に許可しているという仕様の隙を利用します。これらのサーバーはCookieの「かけら（crumb）」を件数制限にカウントしていませんでした。

サーバー	増幅メカニズム	増幅比
Envoy 1.37.2	Cookieバッファへの追加 + アロケータオーバーヘッド	約5,700:1
Apache httpd 2.4.67	Cookieマージ文字列の再構築（各クラム追加ごと）	約4,000:1
nginx 1.29.7	ヘッダーエントリのブックキーピング	約70:1
IIS (Windows Server 2025)	ヘッダーエントリのブックキーピング	約68:1

②HTTP/2 Window Stall——メモリを解放させないSlowloris型ホールド

HTTP/2にはフロー制御機能があります。受信者（クライアント）が「ウィンドウ」を宣言し、サーバーはそのウィンドウサイズを超えるデータを送信できません。

攻撃者がゼロバイトのフロー制御ウィンドウを宣言すると、サーバーはレスポンスを送信できません。サーバーはタイムアウトを避けるために定期的に小さなWINDOW_UPDATEフレームを送り続けます。リクエストは永遠に「完了」しないため、確保されたRAMが解放されることなく蓄積し続けます。

この組み合わせの破壊力：1バイト送信→5,700バイトのRAM確保（Envoy）、そのRAMは解放されない。同じリクエストをストリームと接続をまたいで繰り返すことで、RAMを使い果たすまで増幅が続きます。

Califの研究者は「実際の攻撃では、プロセスをOOMキルさせることは目的としない。OOMキルされたワーカーはすぐに再起動するからだ。より効果的な戦略は、メモリ圧力をキル閾値の直下に維持してサーバーをスワップ状態に追い込み、他のすべてのリクエストを遅延させることだ」と述べています。

テスト結果-1台のPCが何秒でサーバーを落とすか

サーバー・バージョン	増幅比	デモ結果
Envoy 1.37.2	約5,700:1	32GB RAM枯渇：約10秒
Apache httpd 2.4.67	約4,000:1	32GB RAM枯渇：約18秒
nginx 1.29.7	約70:1	32GB RAM枯渇：約45秒
Microsoft IIS（Windows Server 2025）	約68:1	64GB RAM枯渇：約45秒

テストはすべて100Mbpsの接続を持つ単一クライアントマシンから実施されています。

OpenAI Codexが発見

Califのブログで強調されているのが、この攻撃を発見したのは人間の研究者ではなくOpenAI Codexであるという点です。

このサイバー攻撃を構成する2つの手法であるHPACKボムとHTTP/2 Slowlorisは、それぞれ独立して2016年から知られていました。

人間のセキュリティ研究者は10年間、これらを組み合わせて主要5サーバーに対して機能する攻撃として構築することはありませんでした。Codexはコードベースを読み込み、2つの手法が組み合わさることを認識し、組み合わせ攻撃を構築しました。

Califの研究者は「その組み合わせは一度見れば明白だが、人間が誰もこれらのサーバーに対して組み合わせたことはなかったと思われる」と述べています。

さらにCalifは「fix commitが公開され、AIモデルがそのdiffから実際の攻撃コードを生成できる時代になった」ため、Microsoftへの通知後も比較的迅速に公開を決定したと説明しています。

RFC仕様レベルの欠陥という分析

Califが指摘する最も重要な点の一つは、これが5つの独立した実装の「実装バグ」ではなく、RFC 7541（HPACK仕様）のセキュリティモデル設計の根本的欠陥であるという点です。

RFC 7541 §7.3（メモリ消費）は「攻撃者がエンドポイントにメモリを枯渇させようとする可能性がある」と明記し、SETTINGS_HEADER_TABLE_SIZEによる動的テーブルの制限を対策として提示して「問題は解決された」と結論付けています。

しかし、仕様はメモリリスクを「増幅比」という観点でのみ捉えており、HTTP/2がクライアントに接続をほぼ無制限に開放させることができる仕組み——その間に確保したすべてのバイトが固定される——というリスクを見落としています。5つの独立した実装がすべて同クラスのバグを持つという事実が、欠陥は仕様にあることを示しています。

研究者はこのことに個人的な感慨があります。Califの著者は2012年にJuliano Rizzóとともに「CRIME」（HTTPヘッダー圧縮のコンプレッション・オラクル）を発見し、その修正レビューを依頼され、それがHPACKになりました。そのレビュー時に今回の攻撃を見落とした「CRIMEと戦うことに集中しすぎて、爆弾を見逃した」と書いています。

影響範囲—Shodanで確認できる880,000超のサイト

CalifがShodanで実施した調査によれば、SSL/TLSのALPN「h2」（HTTP/2）をサポートし、かつ影響を受ける5サーバー（nginx・Apache・IIS・Envoy・Pingora）のいずれかを実行しているウェブサイトは880,000件超がインターネット上に存在します。

ただし重要な留保として、多くはCDNやリバースプロキシの背後にあります。CDNやリバースプロキシを経由しているシステムは脆弱なHTTP/2エンドポイントを直接公開しておらず、攻撃の難易度が大幅に上がります。自社サーバーを直接インターネットに露出しているケース（エンタープライズのオリジンサーバーを含む）が最も注意を要します。

開示タイムラインとパッチ提供状況

Califのブログが公開した開示の経緯は以下のとおりです。

nginx：2026年4月に開示→翌日にmax_headersディレクティブを実装→1.29.8でリリース。

Apache httpd：2026年5月27日に開示→同日Stefan Eissingが修正（cookieヘッダーをLimitRequestFieldsにカウントする変更）→CVE-2026-49975として識別→mod_http2 v2.0.41としてスタンドアローンリリース。

Envoy：開示日は非公表→2026年6月3日にGHSA-22m2-hvr2-xqc8としてパッチ公開→Califによる検証が進行中。

Microsoft IIS・Cloudflare Pingora：通知済みだが記事執筆時点でパッチは未提供。

CalifがnginxとApacheの修正commitを公開した直後に「AIモデルがそのdiffからMicrosoft IIS・Envoy・Pingoraが同様に脆弱であることを発見した」と述べており、パッチ未提供のサーバーに対する攻撃コードの生成が現実的な脅威となっています。

緩和策と修正バージョン——サーバー別の即時対応

nginx

修正版：1.29.8以降（max_headersディレクティブをデフォルト1000に設定）。

アップグレードできない場合はnginx.confに以下を追加してHTTP/2を無効化：

server {
    listen 443 ssl;
    # http2 off; または listen 443 ssl の後に http2 を省略
    http2 off;
}

Apache httpd

修正版：mod_http2 v2.0.41（スタンドアローンmod_h2リリースから入手可能・httpd trunk）。2.4.x系の正式リリースには未収録のため、スタンドアローン版の適用が必要です。

アップグレードできない場合はHTTP/2を無効化：

Protocols http/1.1

重要な注意：LimitRequestFieldsの削減は部分的な効果しかなく、根本的な対策になりません。LimitRequestSizeの削減は今回の攻撃の「爆弾範囲の縮小」には効果がありますが完全な緩和策にはなりません。

Microsoft IIS・Envoy・Cloudflare Pingora

パッチ提供まで、HTTP/2を無効化するか、リバースプロキシまたはファイアウォールでリクエストごとのヘッダーフィールド数に厳格な上限を設けてください。

共通の緩和策（全サーバー）

Califが推奨する共通の緩和策として、ワーカープロセスのメモリに上限を設定することが有効です。cgroups・ulimit -v・コンテナのメモリ制限などで、ワーカープロセスが数ギガバイト以上のメモリを確保できないようにします。これにより、爆発的なRAM消費が発生してもワーカーがOOMキルされて再起動するため、サーバー全体がスワップ状態に陥ることを防げます。

FAQ

Q. 自分のサーバーがHTTP/2 Bombの攻撃対象か確認する方法はありますか？ A. まず使用しているWebサーバーのバージョンを確認してください。nginx 1.29.8未満・Apache httpd（mod_http2 2.0.41未満）・Microsoft IIS・Envoy・Cloudflare Pingoraを直接インターネットに公開している場合は対象です。CDNやリバースプロキシ（Cloudflare・AWS CloudFront・Fastly等）の背後にある場合は直接的な攻撃難易度が大幅に上がります。

Q. CDNを使っていれば安全ですか？ A. CDNやリバースプロキシを経由している場合、CDNがHTTP/2を終端するためオリジンサーバーが直接攻撃されにくくなります。ただしCDNからオリジンサーバーへの接続がHTTP/2で行われており、かつ悪意あるリクエストがCDNを通過した場合には影響を受ける可能性があります。CDNプロバイダーのHTTP/2実装の安全性も確認してください。

Q. PoC（概念実証コード）が公開されているとは危険ではありませんか？ A. CalifはnginxとApacheにはパッチが提供されており、fix commitのdiffを見ればAIモデルが即座に他のサーバーへの攻撃コードを生成できる状況にある——つまり「秘密にしても意味がない段階」であるとして公開を決定しました。PoC公開はwebサーバー管理者が脆弱性を理解してパッチ適用・緩和策を取りやすくするためです。

Q. 今後HTTP/2を使い続けても安全ですか？ A. パッチ適用済みのバージョンに更新すれば引き続きHTTP/2を安全に使用できます。Califの指摘はHTTP/2仕様（RFC 7541）レベルの設計上の問題であり、将来的にはRFC自体の改訂が求められる可能性があります。