HTTP/2 Bomb 脆弱性への対応：CVE-2026-49975 の影響範囲と緩和策

HTTP/2 Bomb は、最近公開された HTTP/2 のサービス拒否リスクだ。CVE-2026-49975 と関連しており、攻撃者が小さなリクエストでサーバーに大量のメモリを割り当てさせ、それを長時間保持させることで、サービス低下、swap への退避、最終的な利用不能を引き起こす可能性がある。

この問題は「また普通の DDoS か」と誤解されやすい。しかし危険なのはトラフィック量ではなく、メモリ増幅だ。クライアントが送るデータは少ない一方で、サーバーは HTTP/2 のヘッダー圧縮とフロー制御状態の処理で、何倍ものリソースを消費する可能性がある。

運用・セキュリティチームにとって、今重要なのは攻撃の再現ではない。まず HTTP/2 がどこで終端されているかを確認し、該当コンポーネントをアップグレードするか、一時的に HTTP/2 を無効化することだ。

何が危険なのか

HTTP/2 Bomb は、2種類の古い問題を組み合わせている。

1つ目は HPACK に関連する圧縮増幅だ。HTTP/2 はヘッダー圧縮に HPACK を使う。クライアントは短い参照で、サーバーにヘッダー構造を復元・割り当てさせることができる。実装がヘッダーフィールド数、Cookie 分割、内部の簿記コストを十分に制限していない場合、サーバーは小さな入力に対して大量のメモリを割り当てることがある。

2つ目は Slowloris に似た「保持」だ。攻撃側は HTTP/2 のフロー制御を利用し、サーバーの応答を正常に完了させないことで、先に割り当てたメモリをプロセス内に長時間固定できる。

個別に見れば、どちらも新しい考え方ではない。厄介なのは、これらを組み合わせると、高帯域や大量接続がなくてもバックエンドのメモリを危険な状態に押し込める点だ。

まず確認すべきコンポーネント

公開情報で、影響または確認対象として挙げられている HTTP/2 サーバー実装は次の通り。

nginx
Apache httpd
Microsoft IIS
Envoy
Cloudflare Pingora

NVD の CVE-2026-49975 説明は、現在 Apache HTTP Server の mod_http2 に焦点を当てており、Apache HTTP Server 2.4.17 から 2.4.67 までが影響範囲とされている。Red Hat の公告も関連問題を HTTP/2 HPACK のサービス拒否として扱い、httpd、nginx、Envoy などをコンポーネントごとに処理する必要があるとしている。

ここでは2つの点に注意したい。

第一に、すべてのバックエンドアプリケーションサービスが直接このリスクにさらされているわけではない。まず確認すべきは HTTP/2 の終端点だ。公開ロードバランサー、リバースプロキシ、Ingress、ゲートウェイ、CDN のオリジン側、API Gateway、サービスメッシュ入口などが該当する。

第二に、CVE の紐づけやベンダーごとの対象範囲は完全には一致しない。1つの CVE 番号だけを見て、すべてのコンポーネントがカバーされたと判断しないほうがよい。実際に使っている HTTP/2 コンポーネントごとに、ベンダーまたはディストリビューションの公告を確認する。

簡易チェック手順

次の順番で確認するとよい。

公開入口で HTTP/2 が有効か；
HTTP/2 はどこで終端されているか。CDN、WAF、ロードバランサー、Nginx、Apache、Envoy、IIS、サービスメッシュか；
HTTP/2 を終端するコンポーネントのバージョンは、ベンダー修正版の範囲に入っているか；
上流プロキシでリクエストヘッダーフィールド数、Cookie 分割、接続寿命、単一 worker のメモリを制限できるか；
CDN/WAF を迂回してオリジンへ直接接続できる経路がないか。

多くのサイトは CDN 配下に見えても、オリジン IP、予備ドメイン、テストドメイン、管理入口、カナリア入口が HTTP/2 を直接公開していることがある。確認すべきなのはメインドメインだけではなく、「HTTP/2 を受けられるすべての境界」だ。

修正と緩和策

最優先はアップグレードだ。

nginx を使っている場合、公開情報では 1.29.8+ で関連制限が導入されたとされている。アップグレードできない場合は、一時的に HTTP/2 を無効化することを検討する。

Apache httpd を使っている場合は、mod_http2 の修正版に注意する。公開資料では mod_http2 v2.0.41 に修正が含まれるとされている。Red Hat が示す一時緩和策は、該当 virtual host を HTTP/1.1 のみにすることだ。

1

Protocols http/1.1

nginx で一時緩和が必要な場合は、ベンダーやディストリビューションの案内に従って HTTP/2 を無効化する。

1

http2 off;

Envoy、IIS、Pingora、マネージドゲートウェイを使う場合は、それぞれのベンダー公告に従う。Nginx や Apache の設定発想をそのまま適用してはいけない。具体的な制限点や修正方法が異なる可能性がある。

すぐにアップグレードできないシステムでは、次の防御策を検討する。

エッジで単一リクエストのヘッダーフィールド数を制限する。分割された cookie フィールドも含める；
異常に長寿命な HTTP/2 stream を制限する；
HTTP/2 入口に接続数、並行 stream、リクエストレート、メモリ上限を設定する；
worker やコンテナに適切なメモリ上限を設定し、1つのプロセスがホスト全体を引きずらないようにする；
オリジンは信頼済みプロキシからのアクセスだけを受け入れ、WAF/CDN の迂回を防ぐ；
HTTP/2 接続数、アクティブ stream、メモリ急増、swap 使用量、5xx を監視する。

これらはパッチの代替ではないが、修正までの露出時間を減らせる。

リスクが高い場面

リスクが高いのは、だいたい次のような環境だ。

HTTP/2 を有効にした Nginx / Apache / Envoy / IIS が公開インターネットに直接出ている；
API Gateway や Ingress の入口で HTTP/2 が有効；
CDN を迂回してオリジンへ直接アクセスできる；
メモリの小さい単一ホストが複数サイトや複数業務を載せている；
worker / container のメモリ制限がない；
異常接続、stream、メモリの監視がない；
可用性が重要なのに HTTP/1.1 へ素早く戻す手順がない。

サービスが内網限定でも完全には無視できない。内網からの攻撃、テストスクリプトの誤用、サプライチェーンコンポーネントの露出、サービスメッシュ入口の設定ミスにより、公開インターネットの問題が横展開後の可用性問題になることがある。

CVSS だけを見ない

この種の脆弱性はスコアが混乱しやすい。一部資料は CVSS 9.8 を強調している一方、NVD ページでは現時点で CISA-ADP の CVSS 3.1 が 7.5 High と表示され、NVD 自身の評価はまだ補完中だ。

実際の防御では、スコアは最初の判断材料ではない。より実用的なのは次の質問だ。

自分の HTTP/2 入口は影響を受けるか；
インターネットから到達可能か；
ベンダー修正版へアップグレード済みか；
HTTP/2 を素早く無効化できるか；
メモリ、接続、stream レベルの保護があるか；
前段防御を迂回してオリジンへ直行できる経路があるか。

これらの答えが複数不明なら、高優先度で扱うべきだ。

運用側の推奨対応順

次の順で進めるとよい。

すべての HTTP/2 終端点を列挙する；
ベンダー公告と照合し、バージョンと修正状況を確認する；
公開入口とエッジプロキシを優先してアップグレードする；
すぐにアップグレードできない入口では一時的に HTTP/2 を無効化する；
オリジンが信頼済みプロキシからのアクセスだけを許可しているか確認する；
worker、コンテナ、サービスプロセスにメモリ境界を設定する；
HTTP/2 接続、stream、リクエストヘッダーフィールド数、メモリ異常を監視する；
変更ウィンドウ後に、業務アクセスが正常に動くか確認する。

HTTP/2 を無効化すると、性能、接続再利用、一部クライアント体験に影響する可能性がある。それでも、パッチがない、または露出が不明な場合は、無防備なままより安定した一時対応になる。

まとめ

HTTP/2 Bomb の核心は「どれだけ大量のトラフィックを送るか」ではない。「小さなリクエストで大きなメモリ割り当てを発生させ、そのメモリを保持できる」ことだ。そのため、HTTP/2 がデフォルトで有効なエッジサービスでは特に危険になる。

対応時は、急いで再現しようとせず、1つの CVE ページだけを見ない。まずすべての HTTP/2 終端点を洗い出し、Nginx、Apache、Envoy、IIS、Pingora、またはディストリビューションの公告をコンポーネントごとに確認する。アップグレードできるものはアップグレードする。できないものは一時的に HTTP/2 を無効化し、エッジでヘッダーフィールド、接続、stream、メモリ制限を追加する。

参考：Calif の原始公開、NVD CVE-2026-49975、HAProxy 分析、Red Hat RHSB-2026-007