CDNのHTTP/3変換処理を突くDoS攻撃「CDN Tsunami」が公開、オリジン負荷を最大350倍に増幅

要点

• 主要CDNがHTTP/3をHTTP/1.1へ変換する仕様差を悪用し、オリジンサーバーに過大な負荷を与えるDoS攻撃「CDN Tsunami」が研究者により発表された。

• ヘッダー展開を利用して帯域幅を最大350倍に増幅する「HBA」と、オリジンの接続枠を枯渇させる「HCA」の2手法が存在する。

• 大手CDN 6社の検証では、帯域増幅に全6社、接続増幅に5社が影響を受けることが確認された。

• 実環境での悪用は報告されておらず、対策はWebサイト側ではなくCDN事業者側で適用される。

• 2026年8月20日、サイバーセキュリティの研究チームが、主要なコンテンツ配信ネットワーク（CDN）におけるプロトコル変換処理を悪用した新たなサービス拒否（DoS）攻撃手法「CDN Tsunami」を公表した。

• CDNがブラウザとの間で最新の「HTTP/3」通信を行いながら、背後のWebサーバー（オリジンサーバー）向けには旧規格の「HTTP/1.1」へ変換して通信する仕組みの隙を突くものだ。

• 攻撃者が送るわずかな通信量がCDNを経由することでオリジンに対して最大350倍に増幅され、サーバーの帯域や接続リソースを枯渇させる恐れがあるという。

プロトコルのギャップに着目した調査

Web通信の高速化に向けてHTTP/3の普及が進む一方、CDNがエッジ（配信拠点）でブラウザとHTTP/3通信を行うのに対し、オリジンサーバーとはHTTP/1.1で通信する構成が一般的となっている。研究チームはこの「エンドツーエンドでHTTP/3が使われていない」というプロトコルのギャップに着目した。

検証対象となったのは、Alibaba、Baidu、Cloudflare、Amazon CloudFront、Fastly、Tencentの大手CDN 6社だ。調査の結果、帯域幅増幅には6社すべてが、接続数増幅にはCloudflareを除く5社が影響を受けることが確認された。エッジ側でHTTP/3が有効なWebサイトであれば、サイト側の追加設定なしに標的となり得る状態だったという。

QPACKのヘッダー展開を悪用する帯域増幅「HBA」

1つ目の手法「HTTP/3 Bandwidth Amplification（HBA）」は、HTTP/3で導入されたヘッダー圧縮技術「QPACK」を標的にする。
HTTP/1.1には同等の圧縮機能がないため、CDNは受け取った圧縮インデックス値をオリジンへ転送する前に元の生ヘッダーへと展開（復元）しなければならない。これにより、攻撃者が送る数バイトのリクエストが、オリジン側では展開後のサイズとなって到達する。

特にAlibaba、Baidu、Tencentが対応する「QPACK動的テーブル」を利用した場合、約64の並行ストリームにおいて最大350倍の増幅率が測定された。大きなヘッダーを一度CDNのテーブルに登録させ、以降は小さなインデックス値で繰り返し参照する手法だ。実験では、攻撃側の帯域を500Kbps未満（動的テーブル非対応環境でも5Mbps未満）に抑えつつ、オリジン側では終始100Mbpsを超える帯域を消費させた。

なお、静的テーブルのみを用いた場合の最大帯域増幅率は、Baiduが66.06倍、Alibabaが65.8倍、Tencentが54.08倍、Amazon CloudFrontが51.2倍、Cloudflareが48.27倍、Fastlyが36.41倍だった。

多重化ストリームで接続枠を枯渇させる「HCA」

2つ目の手法「HTTP/3 Connection Amplification（HCA）」は、オリジンの同時接続処理能力を標的とする。
Cloudflareを除く5社のCDNは、HTTP/3のHEADERSフレームを受信すると本文の到着を待たずにオリジンへのHTTP/1.1接続を開く仕様となっていた。HTTP/3では1本の通信接続内で複数の通信を同時に行う「マルチプレキシング（多重化）」が可能なため、各ストリームがバックエンドへの個別のTCP接続を発生させる。低速でデータ（DATAフレーム）を送り続けることでリクエストを未完了のまま保ち、バックエンド接続を占有し続けることが可能になる。

接続上限256、タイムアウト300秒のApacheサーバーを用いた実験では、96ストリーム多重化のHTTP/3接続4本で384本のバックエンド接続を強制できた（Fastlyは接続制限のため8ストリーム×48接続を要した）。
これにより一般ユーザーの応答時間はAlibabaで60秒、BaiduとCloudFrontで最大90秒に達してHTTP 504（Gateway Timeout）が返され、Fastlyでも15秒に延びてHTTP 503（Service Unavailable）となった。Tencentは約10秒で接続を切断した。なお、Cloudflareはリクエスト全体をバッファしてからオリジンへ接続するため影響を受けなかった。

実環境での悪用は未確認、対策はCDN側で実施

本攻撃に関するCVE識別番号は未割り当てで、実環境での悪用も報告されていない。調査を受けた事業者のうち、BaiduとTencentは報告を確認して提案された修正を適用した。

なお、研究チームの論文中ではCloudflareとCloudFrontでHTTP/3が初期状態で有効と記述されていたが、公式ドキュメントではCloudFrontの初期設定はHTTP/2であり、Cloudflareも有効化手順が案内されているなど仕様記述に差異も見られる。

研究チームは、実験は自己制限（オリジン上限100Mbps、攻撃者上限30Mbps）の下で行われたが、より大規模な環境にもスケールすると説明している。また、提案された緩和策はすべてWebサイト側ではなくCDNプロバイダー側で適用されるものだとしている。