「HTTP/2 Bomb」公開——nginx・Apache・IIS・Envoy・Cloudflare横断のDoS脆弱性、家庭回線1本で20秒・32GB消費（CVE-2026-49975 / CVE-2026-47774）

この記事は約20分で読めます。

2026年6月2日、カリフォルニアのセキュリティ企業Calif（カリフ）が「HTTP/2 Bomb」と命名した新規リモートDoS攻撃を、PoC（実証コード）付きで公開しました。本件は、nginx、Apache httpd、Microsoft IIS、Envoy、Cloudflare Pingoraという主要Webサーバ群のデフォルトHTTP/2構成に影響するとされています。Apache httpd側の問題にはCVE-2026-49975が割り当てられ、Envoy側ではCVE-2026-47774（GHSA-22m2-hvr2-xqc8、CVSS 7.5 High）として独立にアドバイザリが公開されています。Shodanの調査では880,000を超える公開HTTP/2サーバが該当ソフトウェアを稼働させており、一般家庭の100Mbpsインターネット回線1本から、Apache httpdやEnvoyサーバに対して約20秒以内に32GBのサーバメモリを消費させることが実証されています。本件で特に注目すべきは、攻撃手法そのものではなく「発見の経緯」です——10年以上前から個別に知られていた2つの既知手法を、Calif研究チームと連携したOpenAI Codexがコードベースを読み解いて組み合わせ、これまで試されていなかった攻撃パターンを構築しました。本ブログで継続的に取り上げているAI支援脆弱性発見シリーズ（Theori/Copy Fail、過去Calif/FreeBSD CVE-2026-7270、Dirty Frag）の系譜に、新たな軸を加える事例です。

Calif公式ブログでは、本件の筆頭著者が2012年にJuliano Rizzo氏とともにCRIME攻撃（圧縮を経由した暗号化Cookie漏洩攻撃）を発見した人物であり、当時Googleに在籍してCRIME対応の一環であるHPACK仕様レビューを担当していたことが明かされています。14年を経て、自分自身がレビューしたはずのHPACK仕様の欠陥が、AIによってあぶり出された、という構図です。記事タイトル「Life has come full circle: today we’re releasing an attack I missed.」（人生は一周し、今日、私が見逃した攻撃を公開する）が、技術的事実以上に本件の意味を端的に表しています。

対応状況一覧（2026年6月4日時点）

製品 影響バージョン CVE Calif公開値の増幅率 パッチ・対応状況 運用上の優先度
nginx 〜1.29.7 — ~70:1 ✅ 1.29.8以降（max_headers 追加） 中
Apache httpd 2.4.x系 CVE-2026-49975 ~4,000:1 ✅ mod_http2 v2.0.41以上（本稿確認時点のstandalone最新はv2.0.42。2.4.x安定版未統合、standalone releasesから適用） 高
Envoy <1.39 CVE-2026-47774（CVSS 7.5 High） ~5,700:1 ✅ 1.35.11 / 1.36.7 / 1.37.3 / 1.38.1 高（最優先候補）
Microsoft IIS Windows Server 2025 — ~68:1 ❌ 公式パッチ未公開 高
Cloudflare Pingora 未特定 — 未公表 ❌ 公式リリースなし（PR #903 が進行中） 中

※ PingoraについてはCalifが影響対象として挙げていますが、公開デモ表ではnginx・Apache httpd・IIS・Envoyの4製品のみ増幅率が示されています。本表の「運用上の優先度」は本ブログ側の判断であり、ベンダー公式のSeverityではありません（Envoyのみ公式CVSSスコアあり）。

各製品の詳細な技術背景、攻撃成立条件、推奨される具体的対応については、以下で順に解説します。

攻撃の正体——HPACK増幅とWindow Stallの連結

HTTP/2 BombはHTTP/2プロトコルの2つの仕様要素を組み合わせて成立します。第1の要素はHPACK（RFC 7541）と呼ばれるステートフル・ヘッダ圧縮スキームです。クライアント・サーバ双方が「動的テーブル」を保持しており、一度送信されたヘッダ値はテーブルにエントリされ、以降は1バイトのインデックス参照で再利用できます。第2の要素はHTTP/2のストリーム単位フローコントロール（RFC 9113）で、受信側が広告したウィンドウサイズを超えてはDATAを送信できず、ウィンドウが拡大するまで送信は止まります。重要なのは、クライアントがサーバ側応答のウィンドウを制御する点です。

Califの分析によれば、本攻撃は以下の2段階で構成されます。第1段階は「HPACK Indexed Reference Bomb」と呼ばれる増幅手法です。動的テーブルに1つだけヘッダエントリを仕込み、その後そのインデックスへの1バイト参照を数千回繰り返します。攻撃者の送信は1バイト単位ですが、サーバ側ではエントリ参照のたびにヘッダの完全コピーをメモリ上に再構築する必要があり、サーバ側のper-entry管理オーバヘッドも加わって、サーバ実装によって約70バイト（nginx・IIS・Pingora）から約4,000バイト（Apache httpd・Envoy）の割り当てが発生します。

第2段階は「HTTP/2 Window Stall」と呼ばれるホールド手法です。攻撃者はゼロバイトのフローコントロール・ウィンドウを広告し、サーバが応答送信を完了できない状態に置きます。さらに、1バイトの WINDOW_UPDATE フレームを定期的に送信することで、送信タイムアウトをリセットし続け、サーバ側に確保された全メモリ割り当てを「サーバ側タイムアウトが許容する限り」固定し続けます。これにより、増幅されたメモリ割り当てが解放されないまま積み上がっていきます。

従来の「HPACK Bomb」（Cory Benfield氏が2016年に名付けたCVE-2016-6581）では、大きな値をテーブルに格納して繰り返し参照する形式が主流でした。サーバ実装側はこれに対し「デコード後の総ヘッダサイズ上限」で対策してきました。Califの変種が新しいのは、ヘッダ自体は実質的に空でも、サーバが各エントリに付与する管理データ（per-entry bookkeeping）から増幅が発生する点です。デコードサイズ上限はそもそも「デコードする中身が空に近い」ため発火しません。サーバ実装によっては「ヘッダ件数の上限」で対策する設計（Apache、Envoy）も存在しますが、これに対してはRFC 9113 §8.2.3が明示的に許容している Cookie ヘッダの分割（crumb単位での分割送信）が回避経路として機能します。Apache・Envoyはcrumbを件数カウント対象に含めていなかったため、上限が事実上機能していませんでした。

増幅率と実証データ——Califが公開した主要4サーバの測定値

Calif公式ブログには、サーバ別の増幅率と実証時間が明示されています。Envoy 1.37.2は約5,700:1の増幅率を達成し、約10秒で32GBのメモリを消費させました。Apache httpd 2.4.67は約4,000:1の増幅率で、約18秒で32GBを消費。nginx 1.29.7は約70:1の増幅率で約45秒、Microsoft IIS（Windows Server 2025）は約68:1の増幅率で約45秒で64GBを消費しました。すべて100Mbps接続の単一クライアントからの実証値です。

Envoyの増幅率が突出している理由として、Califは「Envoyが各cookie crumbをバッファに追記する設計のため、4KB のcookie値を32,000回参照させると論理的に約3,600:1（最終的なcookieバイト数を回線送信バイト数で割った値）に達し、実測のRSS比率では複数ストリームで約3,800:1、単一ストリームではアロケータオーバヘッドも加わって約5,700:1に達する」と説明しています。Apache httpdはcrumbごとに結合済み文字列を再構築する設計で、各古いコピーがストリーム完了まで残るため、cookieが空でも約4,000:1の増幅が発生します。

Califは実運用上の助言として「実際の攻撃ではプロセスをOOM Killさせない方が望ましい——OOM Killされたworkerはクリーンな状態で再起動するだけだから——むしろメモリ圧迫をkill閾値の少し下に維持して、ボックスをスワップに追い込み、他のリクエストすべてを低速化させる方が効果的」と指摘しています。これは典型的なDoS攻撃の「派手な落とし方」ではなく、運用環境を慢性的な性能劣化に陥れる手口で、検知の難易度も高くなります。

仕様の根本欠陥——RFC 7541 §7.3とその限界

Califが本件の「教訓」として最も強調するのは、5つの独立したHTTP/2実装すべてが同種のバグを抱えていたという事実です。RFC 7541には §7.3「Memory Consumption」というセクションがあり、「攻撃者がエンドポイントのメモリを枯渇させようとする可能性がある」と明記したうえで、HPACKは SETTINGS_HEADER_TABLE_SIZE で動的テーブルを上限管理しており「対処済み」と整理しています。にもかかわらず、nginx・Apache httpd・Microsoft IIS・Envoy・Cloudflare Pingoraという5つの独立実装が同じクラスの問題を抱えた状態でリリースされていた事実は、欠陥が個別実装ではなく仕様そのものにあることを示している、というのがCalifの主張です。

もう1つの本質的な見落としは、仕様がメモリリスクを「増幅率」のみで捉えていた点です。Califは「70:1の増幅率は、リクエスト完了時にメモリが解放されるなら無害」と整理したうえで、「HTTP/2がクライアントに対して接続をほぼ無料で長時間保持することを許す仕様であるため、確保されたバイトが任意の時間ピン留めされ、増幅率が攻撃可能性に転化する」と指摘しています。すなわち、増幅率と寿命の積こそが本質的なリスクであり、HTTP/2の仕様はこの組み合わせを意識的に防いでこなかった、ということです。

Codexによる発見——「合成能力」の実証

本件で技術的にも、業界の文脈としても特筆すべきなのは、攻撃そのものをCodex（OpenAI Codex）が発見した点です。Califは公式ブログで「両方の手法は10年間公開されていた。Codexがやったのは、コードベースを読み、2つが合成可能であることを認識し、組み合わせた攻撃を構築することだった。組み合わせは見てしまえば明らかだが、それでも私たちが知る限り、これらのサーバに対してこの組み合わせを試した人間は誰もいなかった」と述べています。

本ブログでは、Theori（Copy Fail）、過去Calif（FreeBSD CVE-2026-7270）、Dirty FragといったAI支援による脆弱性発見事例を継続的に取り上げてきました。HTTP/2 Bombはこの系譜に「既知手法の機械的合成による、これまで試されていなかった攻撃パターンの発見」という新軸を加えるものです。これまでのAI支援脆弱性発見は「fuzzing補助」「コードレビュー支援」「diff理解」といった既存手法の延長線上に位置づけられがちでしたが、本件は「ドキュメント化された個別技法を読み、それらが組み合わさったときに何が起きるかを推論する」という、人間の研究者が時間と注意力の制約で見落としがちな領域でAIが優位性を示した事例です。Califは別の指摘も加えており、「Apache修正のコミット自体が攻撃ベクトルを直接開示している。任意の能力あるAIモデルは、これらのdiffをそのまま動作する攻撃コードに変換できる。実際、私たちはこの方法でMicrosoft IIS、Envoy、Pingoraも脆弱であると突き止めた」と述べています。これは「修正コミットがそのまま攻撃の手引きになる時代」のセキュリティ実務にも警鐘を鳴らす内容です。

パッチ状況と開示論争

Califによる開示プロセスは次の通り進行しました。nginxには2026年4月に通知し、nginx側は翌日 max_headers ディレクティブ（freenginxからインポート、デフォルト値1,000）を追加した1.29.8をリリース。Apache httpdには5月27日に通知し、メンテナのStefan Eissing氏が同日中にmod_http2 v2.0.41で修正（cookieヘッダを LimitRequestFields のカウント対象に含めるよう変更）を行い、CVE-2026-49975が付与されました。

Microsoft IIS、Envoy、Cloudflare Pingoraに関しては、Califが「Apache修正コミットが公開された時点で攻撃ベクトルが自動的に開示される。コミットからエクスプロイトまでの距離が極めて短い現状を踏まえ、ユーザーに緩和策を提供するために公開を決断した」と説明しています。同社は同時にこれら3製品のメンテナにも通知済みです。本稿確認時点で、Envoyは6月3日にセキュリティアドバイザリ GHSA-22m2-hvr2-xqc8（CVE-2026-47774、CVSS 7.5 High）でパッチをリリースしており、Califは「攻撃を緩和するように見える。検証中であり、ギャップが見つかれば更新する」と追記しています。Microsoft IISとCloudflare Pingoraは本稿確認時点で公式パッチ未公開ですが、Pingoraについてはリポジトリ上で「Apply safe-by-default H2Options on HTTP/2 handshake」というPR #903がOpenとなっており、Cloudflare側が内部で対応を進めていることを示すコメントが確認できます。

この開示プロセスについては、Calif公式ブログのコメント欄で、Yan Avlasov氏が「OPは責任ある開示ポリシーを無視し、Envoyエコシステムに対する0-dayを公開した。Envoyコミュニティは当該問題のパッチをリリースするプロセスの最中だった」と批判しています。事実関係を整理すると、Envoy GHSA-22m2-hvr2-xqc8 のReporterはRyoga Yamashita氏（Snow-Poijio）として正式にクレジットされており、Califチームの Quang Luong氏とは別の研究者です。すなわち、EnvoyはCalifによる通知とは独立に別経路で報告を受け、対応プロセスを進めていたことになります。なお、Yan Avlasov氏自身も同アドバイザリにAnalystとしてクレジットされています（Coordinator: phlax氏・botengyao氏、Analyst: yanavlasov氏）。Calif公式ブログには「Update Jun 3, 2026: Envoy has released patches that appear to mitigate this attack」という追記があり、Envoy側の対応プロセスが進行中であった事実は事後に確認可能でした。両者の論点は「Apache修正コミットが公開された時点でゼロデイ性は実質的に失われていた」とするCalif側と、「Envoy側のパッチリリースプロセスが進行中の段階で全詳細を公開することは責任ある開示の枠を外れる」とするEnvoyコミュニティ側で、責任ある開示の境界線をどこに引くかという本質的な議論になっています。本ブログとしてはこの是非には踏み込みませんが、AI支援の脆弱性発見が「修正コミット → diff理解 → 別実装での再現確認」という短時間サイクルで進行する現実が、責任ある開示の伝統的な時間軸を圧縮しつつあるという事実は、運用組織のリスク評価にとって重要な観点です。

CRIMEからHPACK、HPACKからHTTP/2 Bombへ——14年越しの系譜

Calif公式ブログのエピローグでは、筆頭著者が2012年にJuliano Rizzo氏とともに発見したCRIME攻撃と本件の関係が記されています。CRIMEはHTTPSの圧縮（gzip）を経由して暗号化されたCookieを推定する圧縮オラクル攻撃で、対応として「ヘッダ圧縮の安全な仕様」が求められた結果、HPACKが設計されました。当時Googleに在籍していたCalif著者はHPACK仕様のレビューを依頼され、レビューを実施しています。本人が当時のレビューノートを読み返したところ、本攻撃を一度も検討していなかったと記しています。「CRIMEと戦うことに集中しすぎて、爆弾を見落とした」というのが本人の総括です。

HTTP/2 Bombは、HPACK Bomb（CVE-2016-6581、Cory Benfield、2016年）、Apache httpdの ~4,000x増幅事案（CVE-2025-53020、Gal Bar Nahum、2025年）、CONTINUATIONフレーム経由のSlowloris型枯渇（CVE-2016-8740）、worker-thread starvation（CVE-2016-1546）といった一連のHTTP/2メモリ枯渇系脆弱性の系譜の上に位置しています。RFC 7541 §7.3 が10年以上にわたって同じクラスの脆弱性を許容してきた事実は、HTTP/2の仕様策定段階で「速度と安全性の両立」をどう設計するかの判断が、長期的な攻撃面拡大に直結することを示しています。

パッチ適用と緩和策

運用組織が取るべき対応は、影響を受けるソフトウェアのバージョン確認、パッチ適用、未パッチ製品の場合は緩和策の実施、というステップで進めます。

nginxを使用している組織は、1.29.8以降にアップグレードします。新しい max_headers ディレクティブが追加されており、デフォルト値1,000で機能します。アップグレードが困難な場合は、http2 off; でHTTP/2を無効化します。

Apache httpdを使用している組織は、mod_http2 v2.0.41以上を 標準のmod_http2リリース から適用するか、httpd trunk版に追従します。本稿確認時点で同リリースのstandalone最新はv2.0.42（v2.0.41の修正を含み、別件のファイル記述子使用最適化を追加）となっています。本稿確認時点で2.4.x安定版にはまだ取り込まれていないため、運用環境では適用前のテストが必要です。アップグレードが困難な場合は Protocols http/1.1 でHTTP/2を無効化します。LimitRequestFieldSize を下げる対応はストリームごとの被害規模を限定しますが、複数ストリーム・複数接続を経由した攻撃は完全には防げないため、部分的な緩和に留まる点に注意が必要です。LimitRequestFields 単独の引き下げは、本件で問題になる重複cookie crumbsがカウントされないため、効果がありません。

Envoyを使用している組織は、GitHub Security Advisory GHSA-22m2-hvr2-xqc8（CVE-2026-47774）を確認し、修正版の 1.35.11、1.36.7、1.37.3、1.38.1 以降へ更新します。アドバイザリでは、影響バージョンは1.39未満、CVSS v3.1スコアは7.5 Highとされています。Envoy公式アドバイザリは技術的な根本原因として、(1) Cookieヘッダ・バイトがリクエストヘッダサイズ検証時に完全にはカウントされないこと、(2) oghttp2/quicheのHPACKヘッダブロック制限がencoded bytesに対して強制されており、decoded header sizeへの対応制限がないこと、の2点を挙げています。修正は両方への対応が必要で、片方のみの修正では完全な解決にはならないとされています。Califは現時点で「検証中」とコメントしているため、追加の検証情報が公開されるまでは併用緩和策（後述）も実施するのが妥当です。

Microsoft IISとCloudflare Pingoraについては、本稿確認時点で公式のセキュリティアドバイザリやリリース済みパッチは確認できないため、HTTP/2を無効化するか、ヘッダ数上限を強制するプロキシ（例：パッチ済みnginx）を前面に配置する構成を検討します。Cloudflare Pingoraについては、GitHub上でHTTP/2ハンドシェイク時に安全なH2Optionsを適用するPR #903がOpenとなっており、Cloudflare側が内部で対応を進めていることを示すコメントも確認できますが、本稿確認時点で公式リリースには至っていません。すべてのサーバに共通する追加緩和策として、worker単位のメモリ上限をcgroups、ulimit -v、コンテナのメモリ制限で厳しめに設定する運用が推奨されます。Califも明示している通り、攻撃を受けたworkerがOOM Killで早めに殺されて再起動する方が、ボックス全体がスワップに沈むより、はるかにマシな失敗モードです。worker 1つが数GBを必要とすることは通常ありません。

仕様レベルの観点として、Califは「『デコード済みヘッダサイズの最大値』と『ヘッダフィールド数の最大値』は別の制限であり、サーバは両方が必要である。あらゆるHTTP/2終端点は、リクエストあたりのヘッダフィールド数を、合計サイズとは独立に上限を設けるべきで、cookie crumbsも含めるべきである。また、WINDOW_UPDATE の有無にかかわらず、停滞したストリームの寿命に上限を設けるべきである」と提言しています。

AI支援脆弱性発見が変える開示と防御のサイクル

HTTP/2 Bombから取り出せる教訓は3層あります。技術的には、HTTP/2のような大規模で複雑なプロトコルでは、個別仕様の安全性を確認しても、複数仕様の合成によって新しい脆弱性クラスが生まれ得る、という事実です。RFC 7541 §7.3が10年以上にわたって「対処済み」と整理してきた領域から、新規の脆弱性クラスが発見されたという事実は、プロトコル仕様策定における「合成能力」（compositional reasoning）の重要性を改めて示しています。

運用観点では、修正コミットがそのまま攻撃の手引きになる時代における、責任ある開示のあり方が問われています。Calif自身が指摘するように、Apache修正コミットが公開された時点で、AI支援を活用すれば他実装の同種バグを「コミットからエクスプロイトまで」数時間〜数日で構築できます。これは伝統的な「90日開示猶予」「ベンダー間調整期間」といったプロセスの前提を圧迫する事象であり、運用側もパッチサイクルを短縮する体制が求められるようになっています。

そしてセキュリティ研究全体の観点では、本件はAI支援脆弱性発見が「既知手法の機械的合成」というニッチで明確な優位性を発揮することを示しました。本ブログでは、Theori（Copy Fail）、過去Calif（FreeBSD CVE-2026-7270）、Dirty FragといったAI支援脆弱性発見を継続してウォッチしてきましたが、HTTP/2 Bombは「人間が10年見落とした合成を、AIが数日で見つけ、しかも複数の独立実装すべてで成立することを確認した」事例として、シリーズの中でも特に重みのある事例です。今後、AI支援研究によって発見される脆弱性は、CVE登録ペース、責任ある開示の時間軸、防御側のパッチ適用速度、すべての面で運用組織に従来とは異なる対応速度を要求するようになるでしょう。

関連記事

ソース

一次情報・公式情報

製品ベンダー情報

  • nginx：max_headers ディレクティブのインポート（freenginx由来）、1.29.8で配布
  • Apache httpd：Stefan Eissing氏による修正コミット、mod_http2 v2.0.41で配布（本稿確認時点でstandalone最新はv2.0.42）
  • Envoy：GHSA-22m2-hvr2-xqc8 / CVE-2026-47774（2026年6月3日リリース、修正版 1.35.11 / 1.36.7 / 1.37.3 / 1.38.1）
  • Microsoft IIS：本稿確認時点でパッチ未公開
  • Cloudflare Pingora：本稿確認時点で公式パッチ未公開（GitHub上のPR #903でHTTP/2ハンドシェイク時の安全なH2Options適用の対応が進行中）

参考情報

slug: http2-bomb-cve-2026-49975-codex-hpack-dos

コメント

タイトルとURLをコピーしました