2026年6月2日、CVE-2026-49975 として公表された「HTTP/2 Bomb」の報告を読んで、最初に感じたのは「これは普通のDoSとは構造が違う」ということだった。
家庭用のPC一台と100Mbpsの回線があれば、32GBのメモリを積んだサーバを数秒で枯渇させることができる。認証も不要、高度な技術も要らない。公表時点で約88万のサイトが潜在的な対象になると報告されていた。
自分たちが管理しているサイトに影響があるかを確認する前に、まず「この攻撃はどこに届くのか」を整理しておく必要があると思った。
「サーバを1台のPCで落とせる」HTTP/2 Bomb とは何か
HTTP/2 Bomb（CVE-2026-49975）は、HTTP/2プロトコルの2つの特性を組み合わせたリソース枯渇型の攻撃だ。
HPACK 圧縮爆弾: HTTP/2 のヘッダー圧縮方式（HPACK）の仕組みを悪用する。攻撃者が送り付ける1バイトのデータが、受信側のサーバで巨大なメモリ確保に膨張する。メモリが急速に消費されていく。
Slowloris 型のフロー制御ウィンドウ保持: HTTP/2 には接続ごとのフロー制御が組み込まれているが、攻撃者はこのウィンドウを意図的に小さく保ち続けることで、サーバのリソースを長時間占有し続ける。
この2つが組み合わさることで、攻撃のコストは極めて低く、サーバへのダメージは非常に大きくなる。
責任ある開示は2026年5月27日。公表が2026年6月2日。修正の状況は以下の通りだ。
| 製品 | 修正バージョン | 開示時点の状況 |
|---|---|---|
| nginx | v1.29.8 | 修正済み |
| Apache httpd（mod_http2） | v2.0.41 | 修正済み |
| Microsoft IIS | — | 未修正 |
| Envoy | — | 未修正 |
| Cloudflare Pingora | — | 未修正 |
なぜ Apache/nginx が狙われるのか（HPACK＋Slowloris の仕組み）
この攻撃が直撃するのは「HTTP/2 接続を自分で終端している Web サーバ」だ。
Apache や nginx で HTTP/2 を有効にしているサーバは、接続ごとに HPACK の状態を管理し、フロー制御のウィンドウを処理する。ここが今回の攻撃のターゲットになる。
攻撃を受けた場合の典型的な挙動は、サーバのメモリが急激に増加し、数秒から数十秒でプロセスがクラッシュするか、OOM（Out of Memory）で強制終了される。CPUやネットワーク帯域に余裕があっても防げない。「帯域が小さい攻撃元でもサーバが落ちる」という非対称性が、このCVEの危険なところだ。
自社サイトは大丈夫か？──攻撃が「届く場所」で考える
影響の有無を判断するシンプルな問いは「HTTP/2 を終端しているのは誰か」だ。
| 構成 | HTTP/2 終端 | パッチ責任 |
|---|---|---|
| EC2 上の nginx ＋ WordPress | 自社管理サーバ | 運用者 |
| VPS ＋ Apache ＋ WordPress | 自社管理サーバ | 運用者 |
| Astro + S3 + CloudFront | CloudFront（AWS フルマネージドエッジ） | AWS（責任共有モデル） |
上の2つは、サーバの管理責任が運用者側にある。CVEが公表された時点で影響調査・検証環境でのテスト・本番適用・動作確認という一連の対応が必要になる。WordPress の CVE 対応コストについては以前に整理したことがあるが、1件あたり数時間から十数時間の工数が発生することは珍しくない。
Astro+S3+CloudFront の構成では、ユーザーからの HTTP/2 接続を受け付けているのは CloudFront だ。
Astro+S3+CloudFront に脆弱な終端サーバが無い理由
この構成のデータフローはシンプルだ。
ユーザー ─── HTTPS / HTTP2 ──→ CloudFront（AWS フルマネージドエッジ）
│
│ HTTP/1.1
↓
S3（静的ストレージ）CloudFront が HTTP/2 を終端する: 利用者から見た HTTP/2 接続の終端点は CloudFront だ。自社で管理する nginx や Apache サーバは存在しない。
CloudFront は影響製品リストに含まれない: 公表された CVE-2026-49975 の影響製品リストに CloudFront は含まれていない。パッチ責任は AWS 側にある（責任共有モデル）。AWS Shield Standard も標準で機能する。
CloudFront からオリジンへの接続は HTTP/1.1: CloudFront から S3 への接続は HTTP/1.1 が使われる。利用者側の HTTP/2 攻撃がオリジンに波及する構造的な経路がない。
ただし、「自社の責務範囲に脆弱な終端サーバが存在しない構造になっている」ということと、「CloudFront 自体が今後も影響を受けない」ということは別の話だ。CloudFront の最新の状況については AWS 公式のセキュリティ情報を参照してほしい。マネージドサービスを使うことで管理責任の範囲は変わるが、確認の責任がゼロになるわけではない。
逆に WordPress 運用で今すぐ確認すべきこと
Apache/nginx + WordPress で運用しているサイトがある場合、まず HTTP/2 が有効かどうかを確認したい。
HTTP/2 の有効状況を確認する
# nginx: http2 ディレクティブの有無を確認
grep -r "http2" /etc/nginx/
# Apache: mod_http2 の読み込み状況を確認
apache2ctl -M | grep http2
# curl で実際の接続プロトコルを確認する
curl -sI --http2 https://yoursite.example/ | grep "HTTP/"HTTP/2 が有効な場合、nginx v1.29.8 以上、または Apache httpd の mod_http2 v2.0.41 以上へのアップデートが必要だ。
パッチ適用の優先度
| 状況 | 推奨アクション |
|---|---|
| HTTP/2 有効かつ修正バージョン未満 | 速やかにアップデート。検証環境でのテスト後に本番適用 |
| テスト環境の準備が間に合わない場合 | HTTP/2 を一時的に無効化して攻撃リスクを下げ、テスト後にアップデート＋再有効化 |
| HTTP/2 無効の場合 | 本 CVE による直接的なリスクは低い。ただしアップデート自体は推奨 |
振り返って：CVEのたびに走る緊急対応コストを構造で減らす
HTTP/2 Bomb の報告を読んで改めて感じたのは、「CVE への対応コスト」は技術力の問題というより、構成の問題だということだ。
パッチが出たら対応する、という運用は間違っていない。ただ、その対応は1件ごとに確実に工数を消費する。影響調査・検証・本番適用・確認。CVEの件数が年を追うごとに増えるほど、この積み重なり方も大きくなる。
静的化で攻撃面そのものを減らすアプローチは、その根本的な削減策として位置づけている。会員機能や動的処理が必要なサービスでは適用できないケースもあるし、移行には一定の初期コストがかかる。それでも「CVEが出るたびに対応が必要な構成」を維持し続けることの長期コストと比べたとき、どちらが合理的かという問いは立てる価値がある。
今回の CVE を機に、管理しているサイトの構成を改めて整理してみるのも悪くないと思っている。
