HTTP/3サーバーをクラッシュさせるQPACKの脆弱性が判明、最大4000倍のメモリ増幅リスク

要点

• セキュリティ企業のFoxIOが、HTTP/3サーバーを単一の接続でクラッシュさせることが可能な脆弱性と概念実証コードを公表した。

• 圧縮ヘッダーの展開処理におけるサイズ制限の不備により、送信データ量の最大約4000倍に及ぶメモリ消費を強制される恐れがある。

• 検証された10種類のスタック中7種類で欠陥が確認され、quic-goやlsquicなどでパッチが公開された一方、Bunやh3などは未修正のままである。

• 影響はサービス妨害（DoS）に限定されており、データの窃盗や任意のコード実行の証拠はなく、実環境での悪用も報告されていない。

• 2026年10月22日、セキュリティ企業のFoxIOは、HTTP/3 Webサーバーをメモリ枯渇によって異常終了させることができる脆弱性を発見したと発表した。この欠陥はHTTP/3における通信データの圧縮仕様に起因するもので、遠隔の第三者が未ログインの状態から単一の接続を行うだけで攻撃を実行できるという。同社は検証結果の開示とあわせて、実際に動作する概念実証（PoC）コードも公開している。

QPACKの展開処理と最大4000倍に達するメモリ増幅の仕組み

今回報告された問題の共通原因は、HTTP/3でリクエストヘッダーを圧縮伝送するために採用されている仕様「QPACK（キューパック：重複するヘッダーフィールドを短いコードに置き換えて転送する仕組み）」の処理実装にある。

通常、サーバーは通信回線上を流れてくる圧縮データだけでなく、メモリ上で元のテキストに展開した後のヘッダーサイズに対しても上限を設ける必要がある。しかし、影響を受けるスタックでは、受信した圧縮データの容量しか検証していなかったり、展開後のサイズ制限を適用するタイミングが遅すぎたりする不備が存在していた。その結果、1回のリクエストを展開する過程で、サーバーが数十万件ものヘッダーエントリをメモリ上に保持してしまう事態が生じる。

FoxIOの検証によると、この増幅率は攻撃の手法やスタックによって大きく異なる。
1つ目の手法では、圧縮された1MBのデータを送り込むことで、Go言語向けライブラリ「quic-go」上で約16万件のヘッダーフィールドへと展開され、約15MBのメモリが占有された。これは送信データ量の約17倍に相当し、quic-go自身のアドバイザリでは最大で約50倍の展開が生じ得ると説明されている。

さらに深刻な2つ目の手法では、約4KBのヘッダーエントリを1つ保持させた上で、1バイトの参照ポインタを用いてそのエントリを数千回繰り返し参照させる。サーバー側が参照のたびに完全なヘッダーエントリを再構築するため、メモリの消費率は跳ね上がる。FoxIOの測定では、LiteSpeedのライブラリである「lsquic」で600〜1800倍、JavaScriptランタイム「Bun」の環境では約4000倍という極めて高い増幅率が確認された。

多様なHTTP/3スタックへの波及と修正の対応状況

HTTP/3はUDP上で通信を行うため、パケットが従来の多層的なフィルタリングを通過してサーバーへ直接届きやすい特性を持つ。さらに、影響を受けるライブラリは主要なWebサーバーやリバースプロキシの基盤として広く組み込まれているため、影響範囲は広範囲に及んでいる。

FoxIOがテストを実施した10種類のHTTP/3スタックのうち、7種類で同一クラスの欠陥が確認された。開示時点における各ソフトウェアの対応状況は以下の通りである。

• quic-go（Caddy、Traefik、cloudflaredなどで採用）: バージョン0.57.0で修正済み（CVE-2025-64702）
• Cloudflare quiche: バージョン0.29.3で修正済み（CVE-2026-12523）
• lsquic（LiteSpeed Web Server、OpenLiteSpeedなどで採用）: バージョン4.9.0で修正済み（CVE番号なし）
• Wireshark: バージョン4.6.2および4.4.12で修正済み（CVE-2025-13945）
• Bun: 未修正（CVE番号なし）
• h3（hyperium）: 未修正（CVE番号なし）
• aioquic / mitmproxy: 未修正（CVE番号なし）

一方で、MicrosoftのIIS、Envoy、ngtcp2/nghttp3、ならびにGoogle版のquicheについては本脆弱性の影響を受けないことが確認されている。これらの実装では、展開処理を完了した後ではなく、デコードを行っている最中に展開後ヘッダーのサイズ上限を検証しているため、メモリの過剰な膨張が防がれているという。

Bunにおける独自実装の欠陥とCPU飽和ループ

今回の調査において、最も深刻な挙動を示したのがBunのHTTP/3サーバー環境である。Bun公式ドキュメントで実験的機能と位置づけられているHTTP/3実装では、ベースとしてlsquicを採用しながらも、ヘッダーメモリの上限を制限する部分を独自コードに置き換えていた。

この独自コードは個別のヘッダー単位でのチェックを行うものの、展開されたヘッダー全体の累計サイズを追跡していなかった。そのため、lsquic本来の64KB制限が機能せず、展開ヘッダーの総量が2GBを超えた時点でコード内のサイズカウンターがオーバーフローを起こしてゼロに戻り、終了条件を満たせない無限ループに突入する欠陥が存在していた。

FoxIOの報告によれば、回線上わずか516KB程度のデータを運ぶ単一のストリームを送り込まれるだけで、サーバーはCPU使用率100%のままハングアップし、復帰することなく新規リクエストの受付を完全に停止するという。

攻撃の影響範囲とパッチ未提供環境での暫定対策

なお、修正対象に含まれているWiresharkの脆弱性は、Webサーバーへの攻撃とは性質が異なる。これはキャプチャデータからHTTP/3プロトコルを解析する「ディセクタ」部分の不具合であり、キーログファイルを用いて通信を復号する際や、復号シークレットを含むファイルを読み込んだ際にクラッシュが引き起こされる。ネットワーク経由で第三者から直接到達可能なサーバー機能ではなく、Wireshark側も本件に関する悪用事例は把握していないとしている。

一連の脆弱性による直接的な被害はサービス妨害（DoS）にとどまっており、データの漏洩や遠隔からの任意コード実行といった深刻な侵害の痕跡は見つかっていない。また、現時点で公に確認された実際の攻撃事例もないと報告されている。

FoxIOは関係各所に対して修正済みバージョンへの早期更新を推奨している。パッチが未提供の環境に向けた当面の暫定措置として、Bun環境ではHTTP/3サーバー機能を外部に公開しないこと、mitmproxyでは起動時に --set http3=false を指定してHTTP/3を無効化することを挙げている。