HTTP/2 Bomb (CVE-2026-49975) ってなんやねん ── 1 バイトを数千倍にする DoS を AI が見つけた

俺の最初の疑問

ニュースで「HTTP/2 Bomb で Web サーバーが数十秒で落ちる」を見た。CVE-2026-49975。認証もいらんらしい。

CVE-2026-49975 ってどんな脆弱性？ 何がそんなにヤバいんや？

セキュリティの一次情報を当たって整理した記録。

まず一言でいうと

HTTP/2 Bomb は 「1 バイト送るだけで、サーバーに数千バイトのメモリを確保させる」認証不要のメモリ枯渇 DoS。HTTP/2 の 2 つの機能を悪用する合わせ技や。

• HPACK 圧縮爆弾：HTTP/2 のヘッダ圧縮 (HPACK) を悪用し、極小のリクエストでサーバー内部に大量の管理メモリを確保させる。
• flow control hold (Slowloris 風)：応答をわざと受け取らず接続を保持し続け、確保させたメモリを解放させない。

攻撃者が送った 1 バイトに対して、サーバーは Envoy で約 5,700 バイト、Apache で約 4,000 バイトのメモリを確保する (この比を「増幅率 5,700:1」と言う)。家庭の 100Mbps 回線から、単一クライアントが約 20 秒でサーバーに 32GB を確保・保持させて落とせる (BleepingComputer / SecurityWeek の報道)。

なぜ 1 バイトが数千倍になるのか

膨張のカギは HPACK の「インデックス参照」。HPACK はヘッダ圧縮で、一度サーバーに覚えさせたヘッダは、次からは短い番号 (インデックス) だけで参照できる ── 番号 1 個は最小 1 バイト。

攻撃はこれを逆手に取る。

1. ヘッダを 1 回だけサーバーの動的テーブルに覚えさせる (種をまく)。
2. その番号を 数千回送る (1 個 1 バイト)。
3. サーバーは番号 1 個ごとに、元のヘッダ全体をメモリに展開・確保する。

だから 1 バイトの番号 → フルのヘッダ確保、が数千回くり返される。これが「圧縮爆弾」の正体や。zip 爆弾 (小さく送って展開で巨大化) を、ヘッダでやってると思えばいい。

何と比べるとわかるか

「特定製品のバグやろ」と思うが、そうやない。HTTP/2 を実装してる広範なサーバーに共通で刺さる。3 つ並べると性格が見える。

	zip 爆弾	HTTP/2 Bomb (今回)	Rapid Reset (2023)
発想	小さい zip が展開で巨大に	小さいリクエストが内部メモリで巨大に	ストリームを大量に開いては即リセット
枯渇させる先	展開する側のディスク / メモリ	サーバーのメモリ	サーバーの処理 (状態管理)
認証	──	不要	不要
横断性	──	HTTP/2 実装ぜんぶ	HTTP/2 実装ぜんぶ

要するに「NGINX にメモリリークのバグがあった」やなく、「HTTP/2 を素直に実装すると、多くの実装で同じ資源枯渇が起き得た」。2023 年の HTTP/2 Rapid Reset と同じ筋の「エコシステム横断 DoS」や。

何が問題なのか

• 増幅率がえぐい：1 バイト送って数千バイトのメモリを確保させる (Envoy 5,700:1)。送る側のコストはほぼゼロ。
• 認証不要・単一接続・家庭回線：特別な踏み台もボットネットも要らん。1 台から ~20 秒で 32GB。
• 対象が広い：デフォルト設定の NGINX / Apache / IIS / Envoy / Cloudflare Pingora。約 88 万サイトが影響範囲と報じられた。
• 未パッチが多い：修正は nginx 1.29.8 と Apache httpd mod_http2 2.0.41 に入ったが、IIS / Envoy / Pingora はパッチ未提供 (執筆時点)。
• 影響は可用性のみ：情報窃取もコード実行もない。けど Web が落ちれば事業は止まる。

図で見る

混乱しやすいポイント

① 「プロトコル欠陥」とも「単一製品のバグ」とも言い切れない

HTTP/2 規格そのものに CVE が付いたわけやない (CVE 番号は Apache が採番)。各実装が「上限設定をサボると刺さる」という共通の前提を持ってた。メモリ使用量の上限・HPACK テーブル管理・接続ごとのリソース制限を厳しくすれば防げる。だからパッチも「HTTP/2 を消す」でなく 「上限を足す」 方向 (nginx は max_headers を追加)。

② 影響は「可用性」だけ

情報を盗まれるわけでもコードを実行されるわけでもない。落ちるだけ。ただ 88 万サイト規模 + 未パッチ多数なので、実害は十分デカい。

③ Rapid Reset (2023) と何が違うか

• Rapid Reset：ストリームを大量に開いては即リセットして、サーバーの処理 (状態管理) を溢れさせる。
• Bomb (今回)：HPACK で状態を膨らませ、flow control で保持してメモリを枯渇させる。

攻め口は違うが、どっちも 「HTTP/2 の機能を仕様どおり使うだけで刺さる」横断系 DoS。

④ 発見が AI ── ここが新しい

セキュリティ企業 Calif が OpenAI の Codex (エージェント AI) を使って発見した (Calif の解説)。「HPACK 爆弾」と「flow control hold」という既知だがバラバラの挙動を、AI が繋いで新しい攻撃チェーンにした。脆弱性の発見が AI で加速する時代の象徴例で、ニュースの肝はここ。

⑤ なぜ既存の上限で防げなかったか

攻撃は Cookie ヘッダを「かけら (crumb)」に細切れにして送る (RFC で許容されてる)。展開後の中身はほぼ空なので合計サイズで見張る上限をすり抜けるのに、サーバー (Apache 等) は crumb ごとに Cookie 全体を結合し直すので、古いコピーが溜まっていく。

たとえ話

• 圧縮爆弾：小さい zip がディスク上で巨大に展開されるのと同じで、小さいリクエストがサーバーメモリで巨大に膨らむ。
• 席だけ占領して帰らない客：レストランで席を確保して注文せず居座る (flow control hold)。席 (メモリ) が解放されず、他の客 (正規リクエスト) が入れなくなる。

ニュースを読むための変換表

ニュースの言葉	つまり何の話？
HTTP/2 Bomb	CVE-2026-49975。HPACK 圧縮爆弾 + flow control hold のメモリ枯渇 DoS
HPACK	HTTP/2 のヘッダ圧縮。動的テーブルを悪用して内部メモリを膨らませる
flow control (hold)	HTTP/2 の受信ペース制御。応答を受け取らず接続を保持してメモリを解放させない
Slowloris	接続を長く保持して枯渇させる古典攻撃。今回の hold 部分の系統
増幅率 (amplification)	送信 1 に対しサーバーが確保する量。Envoy 5,700:1 / Apache 4,000:1
Rapid Reset (CVE-2023-44487)	2023 の HTTP/2 DoS。大量ストリームを即リセットする別系統
max_headers	nginx 1.29.8 が追加したヘッダ数上限のディレクティブ (防御)
OOM	メモリ枯渇でプロセスが kill される状態
Codex / エージェント AI	OpenAI の AI。今回 Calif がこれで脆弱性を発見した

次に答える、設計者の問い で、それがなんやねん？

ニュースの構造まで掴んだ。次は前段 (CDN / プロキシ / Front Door) を持つ立場として「で、自分の現場はどう守るんや？」。

• 前段の Web サーバーが未パッチ (IIS / Envoy / Pingora) なら、HTTP/2 を切るか、ヘッダ数制限の前段を噛ませるか、パッチを待つか、即決できるか。 判断軸は「HTTP/2 を切ったときの速度低下 × 可用性影響 × パッチ ETA」。
• 切り分け：サーバーが急にメモリ枯渇で落ちたとき、Bomb 攻撃か通常スパイクか言えるか。 接続あたりのメモリ・増幅率・応答を読まない接続の滞留、で見分けられるか。

これに答えられると強い。「CVE のニュースを読める」の一歩先 ── 自分の前段の HTTP/2 を、止めるか・制限するかを要件から選べる側に立てる。

深掘りメニュー 次におすすめのトピック

この記事の続きとして、未来の自分が次に掘るといいトピック。

• HTTP/2 のフレームは TCP にどう乗ってるか ── そもそも HTTP/2 がどう流れてるか。HPACK や flow control の下地で、Bomb の理解が一段深まる。
• HPACK の動的テーブル ── なぜヘッダ圧縮が「爆弾」になるのか。今回の増幅の本丸。
• HTTP/2 Rapid Reset (CVE-2023-44487) ── 前回の横断 DoS。並べると HTTP/2 DoS の構造が見える。
• Slowloris ── flow control hold の元になった古典の接続保持攻撃。
• エージェント AI による脆弱性発見 ── 攻撃の発見が AI で加速する流れ。攻守どちらにも効く。