HTTP/2にDoS脆弱性 フロー制御停止でメモリ枯渇

米CERT/CCは2026年7月16日、HTTP/2サーバ実装のフロー制御機構を悪用してメモリを枯渇させるDoS（サービス拒否）脆弱性「VU#885548」を公表しました。攻撃者は認証不要・遠隔から、仕様どおりの正常なフレームだけでサーバのメモリを食い潰せます。影響が確認されたのは Apache Traffic Server、Citrix NetScaler ADC/Gateway、F5 BIG-IP、Meta Proxygen など。まず自社の外部公開ロードバランサ・リバースプロキシでHTTP/2が有効かを確認し、該当ベンダーの修正版適用を検討してください。情報漏えいには至らず、影響は可用性に限定されます。

この記事でわかること

VU#885548 の概要と、割り当てられた3つのCVE
「フロー制御を止めるだけ」でDoSが成立する仕組み
影響が確認された製品と修正版・回避策
掲載118社中「影響あり」は7社という、ベンダー回答状況の実態
情シスが自社の該当有無を判定する手順

何が起きたのか
なぜ「正常な通信」が攻撃になるのか
1. WAFやレート制限で止まるのか
影響が確認された製品と修正版
現場目線の課題：118社中7社しか答えていない
情シスはどうすべきか
中長期の視点
まとめ
出典

何が起きたのか

CERT/CCが公表した Vulnerability Note VU#885548「Denial-of-service vulnerability in HTTP/2 servers via stalled flow-control conditions」は、特定製品ではなくHTTP/2の実装全般にまたがる問題です。日本ではJVNが JVNVU#90338324 として2026年7月17日に転載しました。報告は Okta Red Team、初版公開は7月16日、最終更新は7月23日（リビジョン8）です。関連するCVEは次の3件が確認できています。

CVE番号	対象	公表日	CVSS（提供元）
CVE-2026-59173	Apache Traffic Server	2026-07-18	7.5 HIGH（CISA-ADP, v3.1）
CVE-2026-59762	F5 BIG-IP ほか	2026-07-15	8.7 HIGH（F5, v4.0）／7.5 HIGH（v3.1）
CVE-2026-44909	Meta Proxygen	2026-07-23	7.5 HIGH（Meta, v3.1）

いずれもベクタは AV:N/AC:L/PR:N/UI:N、影響は C:N/I:N/A:H です。つまりネットワーク越しに、認証もユーザー操作も不要で成立し、壊れるのは可用性だけ。データが盗まれる類の脆弱性ではありません。この性質は、緊急度を判断するうえで重要な材料になります。

なぜ「正常な通信」が攻撃になるのか

HTTP/2のフロー制御とは、受信側が「今どれだけデータを受け取れるか」をサーバに申告し、送りすぎを防ぐ仕組みです。1本のTCP接続に複数のリクエスト（ストリーム）を多重化するHTTP/2では、遅い受信者が回線を占有しないよう、これが仕様（RFC 9113）に組み込まれています。攻撃はこの仕様を素直に使うだけです。

SETTINGS_INITIAL_WINDOW_SIZE = 0 を宣言し、「1バイトも受け取れない」と申告する
受信可能量を増やす WINDOW_UPDATE フレームを送らずに黙り込む

サーバ側は送信を止めますが、応答の生成そのものは止めない実装があります。送れない応答ボディはメモリ上のバッファに積み上がったまま、接続が閉じられるかタイムアウトするまで解放されません。攻撃者が大きなファイルを返すURLを選んで同時に大量のストリームを開けば、バッファはストリーム数×応答サイズで膨らみます。CERT/CCは、リソース上限を高く設定している環境では「上限のないメモリ増幅（unbounded memory amplification）」が起こり得るとしており、OOM Killer によるプロセス強制終了、スワップのスラッシング、ワーカープロセスや接続の枯渇、システム全体の応答不能が想定されます。

WAFやレート制限で止まるのか

止まりにくいのが厄介な点です。送られてくるのは不正なペイロードでも異常な形式のリクエストでもなく、RFCに完全に準拠したフレームだからです。シグネチャベースの検知は効きません。リクエスト数も、ストリームを開いたあとは沈黙するだけなので、毎秒リクエスト数（RPS）で見るレート制限にも引っかかりにくい構造です。

これは大量のトラフィックで押し流すDDoS攻撃とは性質が異なります。少ない帯域で、サーバ側の資源管理の甘さだけを突く「非対称」な攻撃です。2023年のHTTP/2 Rapid Reset（CVE-2023-44487）以来、HTTP/2の多重化そのものが持つ資源管理の難しさが繰り返し露呈している、という系譜のなかにあります。

影響が確認された製品と修正版

CERT/CCが「Affected」と明記しているベンダーは、Apache Traffic Server Project、Citrix、F5 Networks、Meta、Red Hat、SUSE Linux、Yahoo Inc. の7社です。このうち具体的な修正版が判明しているものを整理します。

製品	影響を受けるバージョン	修正版・対応
Apache Traffic Server	9.0.0〜9.2.13 / 10.0.0〜10.1.2	9.2.14 以降 / 10.1.3 以降
Citrix NetScaler ADC / Gateway	13.1-63.18 未満 / 14.1-72.61 未満	13.1-63.18 以降 / 14.1-72.61 以降＋`Http2SmallWndTimeout` の設定確認
F5 BIG-IP（Next for Kubernetes / SPK / CNF 含む）	HTTP/2プロファイルを仮想サーバに適用している構成	F5 の記事 K000162231 を参照
Meta Proxygen	v2017.01.16.00〜v2026.07.20.00	修正コミット適用版

いくつか注意点があります。

Apache Traffic Server の影響範囲はNVDの記載と食い違います。NVDは「9.0.0〜9.1.13、9.1.14で修正」としていますが、Apache Software Foundation自身が oss-security に投じたアドバイザリは「9.0.0〜9.2.13、9.2.14で修正」としています。ベンダー一次情報のほうを採るべきです。9.2系を使っていて「NVDの範囲外だから対象外」と判断すると取りこぼします。
Citrixは更新だけでは緩和が完結しない可能性があります。修正版では Http2SmallWndTimeout というパラメータが導入され、CERT/CCのベンダー欄では「30秒に設定する」ことが案内されています。HTTP Strict Profile を使っていない構成では既定値が0のままで緩和が効かない、との指摘もあります（Citrixの公式ページは動的生成のため本稿では直接確認できておらず、二次情報に基づく記述です）。更新後、実機で設定値を必ず確認してください。
Red Hat と SUSE Linux は「Affected」に分類されていますが、CERT/CCのページ上ではステートメント未受領または上流修正の実装予定という状態です。ディストリビューション各社の情報を追う必要があります。なおF5の記事はJavaScriptで動的描画されるため本稿では対象バージョン一覧を確認できておらず、該当製品を使っている場合は必ず記事本体を参照してください。

現場目線の課題：118社中7社しか答えていない

この件で一番引っかかったのは、脆弱性そのものよりもベンダー回答の埋まらなさでした。CERT/CCのVendor Informationには118社が掲載されていますが、内訳は Affected（影響あり）が7社、Not Affected（影響なし）が22社（HAProxy、nghttp2、lighttpd、LiteSpeed、Go、gRPC、Fastly、Cloudflare、ISC など）、残る約89社は「Unknown（状況不明）」です。

そしてnginx、Apache HTTP Server、Apache Tomcat、Node.js、Microsoft、Envoy はいずれもUnknown。日本企業のWeb基盤で最もよく使われている実装群が、そろって「まだ回答が来ていない」状態にあります。

ここで踏み外しやすいのが、Unknownを「影響なし」と読み替えてしまうことです。Unknownは調査した結果の白ではなく、照会に対して回答が返ってきていないという手続き上の状態にすぎません。脆弱性管理をCVE一覧とCVSSスコアで回している組織ほど「自社製品のCVEが出ていない＝対応不要」で処理が止まりがちで、今回のようにプロトコル実装の設計に横断的に潜むタイプは素通りしてしまいます。

加えて、HTTP/2は多くの現場でアプリケーションではなくTLS終端装置側で有効になっています。ロードバランサ、リバースプロキシ、WAFアプライアンス、CDN — 「アプリ担当が知らないところで有効になっている」のが普通で、アプリのライブラリ一覧をいくら眺めても該当有無は分かりません。限られた人員で公開面の構成を全部把握しておくのは簡単ではなく、こういう横断型の脆弱性が出るたびに「うちのHTTP/2ってどこで終端してたか」から調べ直すことになりがちです。

情シスはどうすべきか

優先度は高すぎず低すぎず、というのが実務的な評価です。情報漏えいには至らない（C:N/I:N）一方で、未認証・遠隔から公開サービスを落とせるため、外部公開している収益直結のサービスほど順位を上げるべき、という判断になります。

1. HTTP/2をどこで終端しているかを洗い出す

外部公開しているホストに対して、HTTP/2がネゴシエートされるかは外側から確認できます。

curl -I --http2 https://example.jp/ を実行し、応答の1行目が HTTP/2 200 であればHTTP/2が有効
openssl s_client -alpn h2 -connect example.jp:443 で、ALPNネゴシエーション結果に h2 が返るかを確認

有効だった場合、その通信を実際に終端している機器・ソフトウェア（ロードバランサ、リバースプロキシ、CDN、アプライアンス）を構成図と突き合わせて特定します。ここが今回の該当判定の起点です。

2. 実装によらず効く資源制御を入れておく

該当ベンダーの製品なら修正版の適用と、Citrixの場合はタイムアウト設定値の実機確認まで行います。ベンダーが「Unknown」の場合も含め、CERT/CCが挙げる次の緩和策は特定製品に依存せず効きます。

バッファする応答データにメモリ上限を設ける
1接続あたりの同時ストリーム数を制限する（SETTINGS_MAX_CONCURRENT_STREAMS 相当）
フロー制御が停止したまま進まない接続を、サーバ側から能動的に切断する（アイドル／ストールのタイムアウト）

「上限を高く設定している環境ほど増幅が大きい」という性質上、性能重視で上限を緩めたまま運用している構成が最も危ない点は押さえておきたいところです。

3. 監視で「兆候」を拾えるようにする

攻撃トラフィックはRPSでは目立たないため、見るべきはサーバ側の状態です。Webサーバ・プロキシプロセスの常駐メモリ量、スワップ使用量、OOM Killer のログ（dmesg / journalctl -k）、確立済みHTTP/2接続数とストリーム数。「リクエスト数は増えていないのにメモリだけ伸びる」という組み合わせが典型的なシグナルです。

そのうえで、落ちたときに誰が何を判断するかも決めておきたいところです。IPAのセキュリティインシデント対応机上演習教材は、サービス停止時の判断・連絡の流れを部門横断で確認するのに使えます。自前で長大なチェックリストを作るより、公的な教材で手順の穴を洗うほうが早いはずです。

中長期の視点

HTTP/2の多重化とフロー制御は、本来は回線を効率よく使うための機能です。しかしサーバから見れば「接続の向こうにいる相手が、いつどれだけ受け取るかを制御できる」という構造でもあり、相手の善意を前提にした設計は悪意ある相手のもとで資源枯渇に変わります。Rapid Reset、そして今回のフロー制御スタール。パターンは違っても根は同じで、HTTP/3（QUIC）にも同種のフロー制御機構があります。個別CVEを追いかけるより「公開面のプロトコル終端装置に、資源上限とタイムアウトが入っているか」を定期点検の項目として持つほうが投資対効果が高いと考えます。過去に扱ったnginxの脆弱性やApache Tomcatのアクセス制御回避、Apache HttpComponents CoreのDoS脆弱性と併せて、自社のWeb基盤の棚卸しに使ってください。

まとめ

HTTP/2のフロー制御を意図的に止めるだけで、未認証・遠隔からサーバのメモリを枯渇させられる脆弱性（VU#885548 / JVNVU#90338324）が公表された。影響は可用性のみで、情報漏えいには至らない。
影響が確認されたのは Apache Traffic Server（9.2.14 / 10.1.3 で修正）、Citrix NetScaler、F5 BIG-IP、Meta Proxygen など。Apache Traffic Server の影響範囲はNVDよりベンダー一次情報のほうが広いので、そちらで判定する。
掲載118社のうち「影響あり」は7社、nginx・Apache HTTP Server・Tomcat・Node.js などは「Unknown」。Unknownを影響なしと読み替えず、HTTP/2をどこで終端しているかの洗い出しと、同時ストリーム数・メモリ上限・ストールタイムアウトの設定確認から着手する。