「100MbpsのPC1台で本当にサーバーが落ちるなんてあり得るの?」
「NGINXもApacheも影響と聞いたけど、自社サービスは大丈夫?」
ボス、HTTP/2 Bombっていう新しいDoS攻撃、ちょっと特別すごいらしいんでしゅけど…1台のPCで本当にWebサーバを落とせちゃうんでしゅか?
そうだな。HPACK圧縮の増幅とSlowloris型のフロー制御停止を組み合わせると、100Mbpsクライアントで数十GBのRAMを数秒で食い潰せる。設計上の盲点を突いた厄介な手法だ。
本記事ではHTTP/2 Bomb DoS攻撃の中身と、影響を受けるサーバ、そして公開しているWebサービスをどう守るかを整理します。
WAFや帯域防御だけでは止まらないことを前提に、実装層の対策まで踏み込みます。
- HPACK圧縮増幅とフロー制御停止の組み合わせで、単一クライアントが数秒で枯渇
- NGINX・Apache・IIS・Envoy・Pingoraに影響、IIS等は本稿時点で未修正
- Apache mod_http2 2.0.41がCVE-2026-49975として修正、NGINXは1.29.8で対応
読み終えたあとには、自社が利用するWebサーバの該当有無と、未修正環境で取れる暫定対策が見えてきます。
目次
HTTP/2 Bomb DoS攻撃の概要
まずはHTTP/2 Bombの仕組みを噛み砕いて確認します。
HPACK圧縮を悪用する増幅技法
HTTP/2 BombはHPACK(HTTPヘッダ圧縮)の特性を逆手に取った増幅技法です。
具体的には、攻撃者が一度ヘッダを送ったあと、コンパクト・インデックスで何度も参照することで、1バイトの攻撃入力が数千バイトのサーバ側メモリ確保を誘発できます。
これだけでも増幅率が大きいのですが、本攻撃の核心はその先にあります。
Slowloris型のフロー制御停止でメモリ解放を阻止
増幅で確保させたメモリを、Slowloris型のテクニックで解放させない仕組みが組み合わされています。
攻撃者は『受信ウィンドウを0バイト』と広告し、サーバ側にリクエスト未完了の状態を維持させます。
結果として、リクエストが終わらない=メモリが解放されない、という状態が長時間続き、サーバが容易に枯渇します。
研究者の実測値は以下のとおりです。
- Envoy:32GBのRAMを約10秒で枯渇
- Apache httpd:約18秒で同様に枯渇
- 100Mbps接続の単一クライアントで数十GBのRAMを数秒〜十秒で消費
1台で数十GBって、もうちょっとしたDDoSが個人で完結しちゃうレベルでしゅね…
そうだな。だからこそ、L7の振る舞いを止めることが鍵になる。CDNや帯域制御だけでは不十分だ。
影響範囲と暫定対策のロードマップ
続いて、影響を受ける製品と、本日から動ける暫定対策を整理します。
影響を受けるサーバとパッチ状況
研究者の検証では、主要なWebサーバ・プロキシが軒並み影響を受けることが確認されました。
本稿時点でのパッチ状況は以下のとおりです。
| 製品 | 対応状況 |
|---|
| NGINX | 1.29.8でmax_headers追加により緩和 |
| Apache httpd | mod_http2 2.0.41で修正(CVE-2026-49975) |
| Microsoft IIS | 本稿時点で未修正、暫定対策が必要 |
| Envoy | 本稿時点で未修正、暫定対策が必要 |
| Cloudflare Pingora | 本稿時点で未修正、暫定対策が必要 |
未パッチ環境で取れる暫定対策
未修正のIIS・Envoy・Pingoraを使う環境では、以下の暫定対策が現実解です。
取り組みやすい順に整理しました。
- 影響大かつHTTP/2不要な公開エンドポイントは、HTTP/1.1へ切り替えて凌ぐ
- 前段プロキシ・WAFで『ヘッダ数の上限』と『同時ストリーム数』を抑える
- 異常な接続維持時間や受信ウィンドウ0設定の検知ルールを観測ログに追加
HTTP/2をいったん切れる環境なら、それが一番手堅いんでしゅね!
まとめ
HTTP/2 Bombは、HPACK増幅とSlowloris型フロー制御停止という古典と新型の合わせ技で、単一クライアントから瞬時に枯渇させる新世代のDoSです。
NGINXとApacheはパッチが揃いつつある一方、IIS・Envoy・Pingoraは未修正で、暫定対策を組み合わせて凌ぐ局面が当面続きます。
WAFや帯域防御だけに頼らず、L7の振る舞いを上限値で抑え込む設定を加え、Web基盤の耐性を底上げしていきましょう。