HTTP/3 脆弱性 Header Accordions｜QPACKのDoS、quic-go・Bunの修正版と確かめ方

HTTP/3 脆弱性「Header Accordions」を、FoxIO の Sébastien Féry 氏が2026年10月20日に公表した。HTTP/3 のヘッダー圧縮 QPACK で、展開した後のヘッダーの大きさに上限が効いていない実装があり、認証の要らない遠隔のクライアントが、送った量よりはるかに大きいメモリをサーバーに使わせられる。既定設定のサーバーが1接続でメモリ不足や応答不能になりうる。本記事は防御側の情報に絞り、影響を受ける実装と直った版、まだ直っていない実装の当面の手当て、自分の環境の版の確かめ方を、各リポジトリのタグと公開アドバイザリで 2026-10-22 に確かめた結果でまとめる。

依存しているライブラリの穴を追う全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。

HTTP/3 脆弱性 Header Accordions の時系列

FoxIO は 2025年11月から実装ごとに報告し、2026-10-20 に公表した。報告日は FoxIO の公表、修正版の日付は各実装のタグとパッケージの公開日（proxy.golang.org・crates.io・PyPI・npm）で突き合わせた。

何が起きるのか：QPACK で展開した後の大きさに上限が効いていなかった

HTTP/3 はヘッダーを QPACK（RFC 9204）で圧縮して送る。受け手は展開してから名前と値の組を組み立てる。RFC 9114 §4.2.2 はヘッダーの大きさの上限を展開後の大きさで数え、1項目ごとに32バイトを足すと定めている。受け手はこの上限を SETTINGS で相手に伝える。

FoxIO によると、影響を受けた実装は展開後の上限が無いか、数え方が不完全か、上限を当てるのが遅かった。quic-go のアドバイザリでは、同社の実装は圧縮されたフレームの大きさ（サーバーの既定は 1MB）だけを制限し、展開後の大きさを数えていなかった。展開すると圧縮時のおよそ50倍まで膨らみうるという。

入口は HTTP/3 で接続できることだけで、認証は要らない。quic-go のアドバイザリは、ヘッダーの組み立てがサーバーとクライアントで共通のためクライアントも影響を受けるとしている（悪意あるサーバーに接続した場合）。

どんなヘッダーをどう組むと膨らむかは、本記事では書かない。防御側が確かめるのは「展開後の上限が効く版か」と「HTTP/3 の口を外に出しているか」の2点で、どちらも次の表とコマンドで分かる。

DoS攻撃 対策：実装ごとの修正版と、まだ直っていない実装の手当て

実装ごとの状況（2026-10-22 時点）

quic-go の2件はどちらも Moderate（CVSS 3.1 の基本値 5.3、可用性だけに影響）。quiche 0.29.3 には「qpack: fix size calculation when decoding」と「h3: implement a default for SETTINGS_MAX_FIELD_SECTION_SIZE」のコミットが入っている。lsquic 4.9.0 の CHANGELOG には「Limit number of buffered header sets to cap memory use」とある。

Bun：2026-10-21（米国時間）に main へ入った PR #46392 は、HTTP/3 のヘッダーの大きさを RFC 9114 §4.2.2 の数え方で強制し、サーバーは告知した上限（--max-http-header-size、既定 16KB）を超える要求に 431 を返すと説明している。10-22 時点で安定版 1.4.3（10-10 公開）には入っておらず、公開時刻から見て canary 1.4.3-canary.20261021.1 にも入っていない。PR の説明は FoxIO の報告に触れていない。Bun HTTP/3 サーバー（Bun.serve({ http3: true })）を外に出しているなら、修正入りの版が出るまで HTTP/3 を外す。

h3：crates.io の最新は 0.0.8（2025-05-06）。main の max_field_section_size の既定は VarInt の最大値で、事実上の上限なしのまま（2026-09-20 のコミット時点）。FoxIO によると、メンテナーはアルファ版のライブラリとして既定値を変える予定と答えた。サーバーを組むときに h3::server::builder() の max_field_section_size で、アプリが受け付ける大きさに合った値を入れる（参考までに Bun の HTTP/3 サーバーは既定 16KB）。

aioquic と mitmproxy：aioquic 1.7.0（10-16）の変更履歴に該当する修正は無い。mitmproxy 12.3.0（10-22）も変更履歴に該当する修正が無く、aioquic を 1.2.0 に固定している。mitmproxy HTTP/3 の受け口（http3 オプション）は既定で有効なので、要らなければ --set http3=false で切る。aioquic を使う hypercorn で HTTP/3 を有効にしている場合も、修正が出るまで外に出さない。

Caddy・Traefik・cloudflared は、どの版から直った quic-go を含むか

各プロジェクトのタグの go.mod から quic-go の版を拾った。公式のビルドはこの版で組まれる。

Caddy は v2.10.2 まで quic-go 0.54.0 以下だった。cloudflared は quic-go を自社のフォークに差し替えており（go.mod の replace）、2026.8.0 から「This fork is based on quic-go v0.59.1」と注記している。2026.10.3 のソースには quic-go の HTTP/3 パッケージを読み込む箇所が無く、quic-go はエッジへのトンネル（QUIC）に使われている。FoxIO は cloudflared を利用先に挙げているが、影響の有無について Cloudflare の告知は確かめられていない。2026.8.0 以上に上げておけば、どちらでも差し支えない。

自分の環境で HTTP/3 脆弱性の影響を確かめるコマンド

確かめるのは版と、HTTP/3 の口が開いているかだけ。攻撃の再現はしない。下の3つのコードブロックは、対象を入れた環境（UDP 443 は待ち受けあり）と、何も入れていない環境の両方で、掲載したまま実行して出力を確かめた（2026-10-22、Linux x86_64、Go 1.24.7・cargo 1.97.0・Python 3.13）。

# Go のモジュール：選ばれている quic-go の版（go.mod のあるディレクトリで）
go list -m github.com/quic-go/quic-go
# ビルド済みの Go バイナリ：中に入っている quic-go の版（例は caddy。traefik・cloudflared も同じ形）
go version -m "$(command -v caddy)" | grep 'quic-go/quic-go'

go list -m は github.com/quic-go/quic-go v0.59.1 のように版を返し、replace で差し替えていれば => の後ろに実際に使う版が出る。依存していなければ not a known dependency で終わる。go version -m は dep github.com/quic-go/quic-go v0.54.0 の行を出す（Caddy v2.10.2 をソースから組んで確かめた）。grep を quic-go だけにすると quic-go/qpack の行も拾うので、quic-go/quic-go で絞る。ソースから組んだ caddy は caddy version が unknown を返したので、版は go version -m で見るほうが確実。

# Bun の版（Bun.serve で http3 を有効にしているかはコードで確かめる）
bun --version
# aioquic と mitmproxy の版（使っている Python 環境で）
python3 -m pip show aioquic mitmproxy 2>/dev/null | grep -E '^(Name|Version)'
# Rust のプロジェクト：h3 と quiche の版（Cargo.toml のあるディレクトリで）
cargo tree -i h3 --depth 0
cargo tree -i quiche --depth 0

mitmproxy 12.3.0 を入れた環境では Version: 12.3.0 と、依存の aioquic の Version: 1.2.0 が並ぶ。cargo tree -i は h3 v0.0.8 のように1行返し、依存に無ければ did not match any packages のエラーになる。

# UDP の 443 番で待ち受けているプロセス（HTTP/3 の口が開いているかの目安）
sudo ss -ulnp 'sport = :443'

影響範囲：サーバー・クライアント・解析ツール

・HTTP/3 を受け付けるサーバー：影響の中心。1接続でメモリ不足や応答不能になりうる（FoxIO）
・クライアント：quic-go では、悪意あるサーバーに接続したクライアントも影響を受ける（アドバイザリ）。Bun の PR #46392 も fetch の HTTP/3 クライアントに上限を設けている
・Wireshark：止まるのは通信を解析する側。リリースノートの記載は「HTTP3 dissector crash」で、該当する HTTP/3 の通信を解析すると止まる
・影響なし（FoxIO）：IIS（http.sys）・Envoy・ngtcp2/nghttp3・Google quiche。nghttp3 は上限を相手に伝えるだけで、強制はアプリ側の責任だとドキュメントに明記した（PR #445）。nghttp3 を直接使うアプリは自分で上限を強制する
・見分け方：FoxIO は自社のスキャナー JA4Scan で、影響を受ける版のサーバーを見分ける指紋を公開している

本件とは別に、nginx の HTTP/3 モジュールにも CVE-2026-42530 が出ている。nginx を使っているなら nginx CVE-2026-42055/42530/48142 解説 で条件と修正版を確かめてほしい。依存ライブラリの脆弱性が一度に複数出たときの直す順番は、npm audit の結果はどれから直すか で到達性から仕分ける手順を書いた。HTTP/3 を外に出していない依存は、後回しにできる側に入る。

参照ソース

・FoxIO: Header Accordions — QPACK Amplification Attacks Against HTTP/3 Servers（2026-10-20）
・GHSA-g754-hx8w-x2g6：quic-go HTTP/3 QPACK Header Expansion DoS（CVE-2025-64702）
・GHSA-vvgj-x9jq-8cj9：quic-go HTTP/3 QPACK Trailer Expansion（CVE-2026-40898）
・GHSA-4fgf-9xrr-88gf：Cloudflare quiche（CVE-2026-12523）
・lsquic CHANGELOG（4.9.0・2026-07-15）
・Wireshark wnpa-sec-2025-07
・oven-sh/bun PR #46392（2026-10-21）
・ngtcp2/nghttp3 PR #445：Clarify field size limits
・mitmproxy CHANGELOG（12.3.0・2026-10-22）
・RFC 9114 §4.2.2 Header Size Constraints・RFC 9204 QPACK