CERT/CC が通知した 118 社のうち、影響ありは 7 社、影響なしは 22 社。残る 89 社は、どちらでもありません。nginx も Microsoft も Node.js も、この 89 社の側にいます。回答がないという状態は、自社のサーバーを守る立場から見ると、影響ありよりも扱いに困ります。動くべきか、様子を見るべきかの判断材料が、そもそも存在しないからです。
2026年7月16日、CERT/CCがHTTP/2サーバー実装のサービス妨害脆弱性を公開した。認証を持たない攻撃者がメモリ枯渇を引き起こし、サーバーを停止させ得る。攻撃者がRFC 9113のフロー制御を操作して送信を停滞させると、一部の実装は送信できないままレスポンスを生成し続け、ストリームごとにデータがメモリへ蓄積する。Okta Red Teamが報告し、VU#885548として整理された。
CVE-2026-44909、CVE-2026-59173、CVE-2026-59762が割り当てられている。影響ありとされたのはApache Traffic Server、Citrix、F5 Networks、Meta、Red Hat、SUSE、Yahoo。通知先118社のうち、22社が影響なしと回答し、89社は影響の有無が確定していない。
From: 
New HTTP/2 Vulnerability Lets Hackers Crash Servers With Memory Exhaustion Attacks
【編集部解説】
この一件を「HTTP/2というプロトコルに欠陥が見つかった」と読むと、対策の当たりどころを外します。問われているのは仕様ではなく、フロー制御が停滞したときにサーバーがどう振る舞うか——その実装の差です。
差が生まれる場所は一つではありません。バッファに上限を設けているか、同時ストリーム数の制限を本当に強制しているか、停滞した接続を打ち切るタイムアウトがあるか。CERT/CCが対策として挙げるのもこの3点で、裏を返せば、そのどれかが欠けている実装が影響を受けたということです。
設定値が分岐点になった例が、影響なしと回答したFastlyです。同社が使うh2o実装では、上流データ用バッファの上限がSIZE_MAX（実質無制限）のままだと問題が成立します。Fastlyはこれを小さな値に変更して運用していたため、再現しませんでした。ここでは、出荷時の初期値をそのまま使ったかどうかが分かれ目になっています。
一方、Apache Traffic Serverの事例はまったく別種です。こちらを説明したのはプロジェクト本体ではなくYahoo Inc.でした。プロジェクト側の回答欄は空のままです。
Yahooの説明によれば、同時ストリーム数の上限 proxy.config.http2.max_active_streams_in は「勧告的」な扱いにとどまり、強制されていませんでした。クライアントが上限より速くストリームを開けば、制限が効く前に通り抜けてしまう。9.2.14と10.1.3では、超過分をREFUSED_STREAMで拒否する強制執行へと改められています。設定値の問題ではなく、強制する実装そのものが欠けていたケースです。
RFC 9113は、受信側が通知した同時ストリーム数の上限を維持し、超過分にはPROTOCOL_ERRORまたはREFUSED_STREAMを返せると定めています。強制されない上限は上限ではない、という古典的な教訓が、仕様の側にはすでに書かれていたことになります。
「影響なし」と「確定していない」は違う
CERT/CCの一覧には118のベンダーが並び、その多くには5月5日付で通知が届いています（IETF関連の2件のみ4月14日、ほかに5月7日から13日にかけて通知された数社がある）。公開は7月16日、最終更新は7月23日。主要な通知から公開まで72日が置かれた計算になります。
注意深く見るべきは、この一覧が「影響あり」「影響なし」の二色ではなく、三色で塗られている点です。CSAF形式の公開データで確認すると、内訳は影響あり7社、影響なし22社、そして未確定89社。全体の4分の3が3つ目の色で塗られています。
nginx、Apache HTTP Server、Microsoft、Google、Amazon、Node.js、Envoy、Apache Tomcat、Netty——Webインフラの中核を担う名前が、そろってこの欄に並んでいます。NEC、ソニー、東芝といった日本企業も通知先に含まれており、いずれも回答は届いていません。
ここで正確を期すと、この区分が意味するのは「CERT/CCの公開記録では影響の有無が確定していない」ということであって、各社の内部で何も分かっていないという意味ではありません。ただし、少なくとも公開情報を頼りに自社構成を照合しようとする立場からは、安全側の材料が存在しないことに変わりはありません。
一方で影響なしと明言したのは、CloudflareとAMDだけではありません。Fastly、GitHub、HAProxy、lighttpd、LiteSpeed、nghttp2、Go、gRPC、ISC BINDなど、22社が個別に検証結果を返しています。ISCは、64KBのDNS応答と100並列クエリという人工的な条件下でも、HTTP/2＋TLS接続あたりのピークメモリが約1.6MBにとどまったと実測値を示しました。
自社の構成が該当するかどうかは、報道の一覧ではなくベンダーの原文で確かめるほかない。それが実務上の結論です。
どのCVEが、どの製品を指すのか
元記事を含め、多くの報道は3つのCVE番号を並列に挙げるだけで、対応関係を示していません。しかし読者が自社機器を照合するとき、最も必要になるのはまさにこの対応表です。
CERT/CCの各ベンダー欄に付されたCERT Addendumと、ベンダー公式のアドバイザリを突き合わせると、次のように整理できます。
| CVE番号 | 対応する実装・製品 | 出所 |
|---|---|---|
| CVE-2026-44909 | Meta「Proxygen」 | CERT Addendum |
| CVE-2026-59173 | Apache Traffic Server | CERT Addendum／Apache公式 |
| CVE-2026-59762 | F5 BIG-IP | F5 K000162231 |
| CVE-2026-13474 | Citrix NetScaler ADC / Gateway | Citrix CTX696604 |
4つ目の番号に気づいたでしょうか。Citrixは自社の速報でこの問題をCVE-2026-13474として扱っており、CERT/CCの一覧がCitrixをCVE-2026-59173の影響ありと記載している点と、番号が一致しません。
そしてこのずれはCitrixだけの話ではありません。F5欄、Meta欄でも、ベンダーステータス表の表示とAddendumや公式CVEとの間に同様の不整合が見られます。CERT/CCのステータス表だけを機械的に取り込むと、誤った対応関係を資産管理台帳に流し込むことになります。
実務としては、VU#885548を親の追跡番号として登録し、その下に製品ごとのベンダー公式CVEをぶら下げる形が安全です。上の表も、CVEと製品の一対一対応というより「どの資料を見に行くべきかの索引」として使うのが正確な扱いになります。
「アップデートしただけ」では塞がらない
とくに手を動かす必要があるのがCitrixのNetScalerです。修正版（NetScaler ADC / Gateway 14.1-72.61以降、13.1-63.18以降ほか）へ上げるだけでは、多くの環境で対策は完結しません。
修正版で新設されたHttp2SmallWndTimeoutは、ウィンドウが小さいまま停滞したストリームを打ち切るまでの秒数を制御するパラメータですが、HTTP Strict Profilesを使っていない構成では初期値が0、つまり無効です。この場合、管理者が手動で30秒に設定して初めて塞がります。アップデート＝対策完了、という反射的な理解が通用しない典型例です。
なお、Citrixがこの問題を公表したのは6月30日の速報CTX696604であり、CERT/CCの公開より16日早いタイミングでした。この速報はCVE-2026-13474を含む6件を一括で扱っており、うちCVE-2026-8451、CVE-2026-8452、CVE-2026-8655の3件がCVSS v4で8.8。HTTP/2の件だけを抜き出して適用する運用は、そもそも想定されていません。
F5のBIG-IP側はCVE-2026-59762として整理され、CVSS 3.1で7.5（HIGH）、CVSS 4.0では8.7と評価されています。仮想サーバーにHTTP/2プロファイルを設定している場合にメモリ使用量が増大し、TMMプロセスが再起動を強いられるまで性能が劣化します。修正は17.1.3.4 / 17.5.1.8 / 21.0.0.3 / 21.1.0.1で導入されました。BIG-IP Next系など別系列の製品もあるため、対象範囲は公式アドバイザリで確認する必要があります。
「仕様は悪くない」と言い続けて7年
このアドバイザリで最も読み応えがあるのは、実はIETF HTTP Working Groupが寄せたコメントかもしれません。
彼らの立場は明快です。この開示が向けられるべき先はHTTP/2仕様ではない。仕様に対する脆弱性報告はこれまでにも繰り返されてきたが、いずれも仕様そのものの問題だったことはなく、問題は常に実装の側にあった。そう述べたうえで、それでもこの種の不具合は十分に頻出しており、RFCを改訂する機会があれば実装者向けの助言として書き加える価値はありそうだ、との見方も添えています。
原理としては筋が通っています。ただ、同じ種類のバグが実装者を替えて何度も再発しているという事実は、「仕様が悪いか実装が悪いか」という二分法そのものの限界も示しているように、筆者には見えます。これは一次資料から直接導かれる事実ではなく、記録の並びを見た筆者の解釈です。
その再発ぶりは記録が裏づけます。影響なしと回答したTempestaは、今回の攻撃を2019年のData Dribble（CVE-2019-9511）の類縁と位置づけ、自社のCIが同種の挙動を継続的に検知していると説明しました。技術的に同一の手法というわけではありませんが、7年前にカタログ化された原理が、別の実装で再び通用していたことになります。
2026年に限っても、3月にNode.jsのメモリリーク（CVE-2026-21714）、5月にApache httpdのmod_http2における二重解放（CVE-2026-23918）、6月にはHPACKの増幅とフロー制御停滞を組み合わせたHTTP/2 Bomb（CVE-2026-49975）が公表され、そして7月に今回のVU#885548が続きました。半年で4件。件数だけで構造的だと断じるつもりはありませんが、無関係な偶然が並んだとも考えにくい密度です。
送りつけるのではなく、握ったまま離さない
防御側にとって厄介なのは、この攻撃が「大量に送りつける」型ではないことです。
2023年のRapid Resetは、記録的な秒間リクエスト数を叩き出す物量戦でした。対して今回は、認証不要の接続から、仕様どおりに正しく組み立てられたフレームを送るだけで成立し得ます。大規模な帯域は必要としません。ただし、どこまで実害が出るかは実装、要求するリソースのサイズ、同時に開くストリーム数に大きく依存します。GitHubは提供されたPoCで影響を再現できず、実用上のインパクトは限定的か、ごく一部の利用形態に限られるとの見解を示しています。
検知の難しさについても、正確に言い直しておきます。帯域やリクエストレートだけを見る単純なフィルタリングでは見逃しやすい、というのが実態です。反応する材料がないわけではありません。1接続あたりの同時ストリーム数、接続の継続時間、ゼロウィンドウのまま滞留しているストリームの割合、要求されているリソースのサイズ——これらは観測可能な指標であり、CERT/CC自身も、ストリーム数の制限と停滞接続の能動的な切断を対策として推奨しています。
そのうえで、監視の軸をトラフィック量からサーバー内部の状態へ移すことには意味があります。メモリ使用量の異常な立ち上がり、応答生成済みなのに送出されていないバッファ量。見るべき指標は、ネットワークの外側ではなく内側にあります。
深刻度の評価そのものは、まだ収斂していません。同じVU番号の下に、影響あり・影響なし・再現不能が混在し、製品ごとのCVEスコアも異なります。単一の数値でこの脆弱性の危険度を語れる段階ではない、というのが現在地です。
速さのために足したものが、脆さになる
HTTP/2が導入した多重化、ヘッダー圧縮、フロー制御は、いずれもWebを速くするための機能でした。近年のHTTP/2脆弱性は、そのすべてを一度ずつ攻撃面として通過しています。説明の便宜として整理すれば、多重化はRapid Resetに、ヘッダー圧縮はHTTP/2 Bombに、そしてフロー制御は今回のVU#885548に。もっとも実際にはどれも複合的で、Bombはフロー制御も併用しますし、今回もバッファ管理の問題を含みます。
性能を上げるためにサーバー側へ状態を持たせれば、その状態を握ったまま離さない相手が現れる余地も、同時に生まれます。速度と堅牢性のあいだにあるこの緊張関係は、HTTP/3とQUICが主流になったあとも形を変えて残るだろうと考えています。
新しいプロトコルを迎え入れるとき、確認すべきなのは仕様書の記述だけではありません。その実装が出荷時にどんな初期値を選んでいるか、そして書かれている制限が本当に強制されているか——今回の一件は、その2つを見に行く必要を示しています。
【編集部後記】
Citrix がこの問題に付けた番号は CVE-2026-13474、CERT/CC が Citrix の欄に表示している番号は CVE-2026-59173。同じ現象に、別の名前が2つ付いています。しかも同種のずれは F5 と Meta の欄にもあり、Citrix だけの例外ではありません。
脆弱性管理ツールに CVE を流し込んで自動照合している現場では、この不一致はそのまま検知漏れになります。片方の番号でしかヒットしない台帳は、パッチが当たっていない機器を「対応済み」と表示してしまう。番号の付け方は各社の裁量に委ねられていて、統一を強制する仕組みは今のところありません。
ベンダーが 100 社を超える協調的開示で、追跡番号を1本に束ねる責任は誰が負うべきなのでしょうか。CERT/CC の VU 番号がその役割を担うのだとしたら、資産管理の側も CVE ではなく VU を主キーにする作りへ変えるべきなのかもしれません。
【用語解説】
HTTP/2
2015年5月にRFC 7540として標準化されたWebの通信プロトコル。1つの接続で複数のやり取りを並行処理する「多重化」により、HTTP/1.1で生じていたアプリケーション層の待ち行列（head-of-line blocking）を大きく軽減した。ただしTCP層の待ち行列は残る。現在も最も広く使われる方式の一つだが、HTTP/3やHTTP/1.xも相当の割合を占める。
RFC 9113
HTTP/2の現行仕様書。2022年6月に発行され、RFC 7540を廃止した。多重化、フロー制御、ストリーム管理を規定する。ヘッダー圧縮についてはHPACKの利用を定めるが、そのアルゴリズム自体はRFC 7541に規定されている。
ストリーム／多重化（マルチプレキシング）
1本のTCP接続の中に開かれる論理的な通信路が「ストリーム」であり、これを同時に多数開く仕組みが多重化である。速度向上の中核だが、攻撃者にとっては「1接続で大量の要求を投げる手段」でもある。RFC 9113自体、同時ストリーム数の制限をDoS対策として重視している。
フロー制御
受信側が「今どれだけ受け取れるか」を送信側に伝え、処理能力を超えるデータの流入を防ぐ仕組み。受信側が主導権を握る設計であり、今回はその主導権が悪用された。
SETTINGS_INITIAL_WINDOW_SIZE
接続開始時に、クライアントが「受信可能なデータ量の初期値」をサーバーへ通知する設定項目。これを0にすると、サーバーはレスポンス本体（DATAフレーム）を送信できなくなる。HEADERSなど制御系のフレームは影響を受けない。
WINDOW_UPDATE
「もう少し受け取れる」と受信枠の追加をサーバーへ知らせるフレーム。送信窓を使い切ったあとにこれを送らずにいると、そのストリームのDATA送信は停止したままになる。
メモリ増幅（memory amplification）
攻撃者が投じるコストに対し、サーバー側で消費されるリソースが不釣り合いに大きくなる状態を指す。増幅の倍率は実装と要求内容によって大きく異なり、一般値は示されていない。
OOM kill
メモリを使い切った際に、Linuxカーネルが強制的にプロセスを終了させる保護機構。必ずしも対象のサーバープロセスが選ばれるとは限らないが、サービス側から見れば予告なしの停止につながる。
スワップスラッシング
物理メモリが不足し、ディスク上の退避領域との間でデータの出し入れが延々と繰り返される状態。プロセスは生きているが、応答速度は実質的に停止に近づく。
REFUSED_STREAM
処理を始める前に拒否したストリームを示すエラーコード。RFC 9113は同時ストリーム上限の超過時にも使用できると定めている。Apache Traffic Serverはこれを使い、従来「勧告的」だった上限を強制執行へ切り替えた。
HPACK
RFC 7541が定めるHTTP/2のヘッダー圧縮方式。あらかじめ定義された静的テーブルと、通信の中で構築される動的テーブルを番号で参照して転送量を削減する。この参照の仕組みを悪用したのが、2026年6月のHTTP/2 Bombである。
SIZE_MAX
C言語の size_t 型が扱える最大値を表す定数。Fastlyの説明によれば、同社が使うh2o実装では上流データ用バッファの上限にこの値が設定されている場合に今回の問題が成立する。他の実装にそのまま当てはまる前提条件ではない。
Data Dribble（CVE-2019-9511）
2019年に公表されたHTTP/2のDoS脆弱性群のひとつ。大きな応答を要求したうえで受信ウィンドウと優先度を操作し、サーバーに1バイト単位のキュー処理を延々と行わせてCPUとメモリを消費させる。今回の攻撃と原理を共有する。
Rapid Reset（CVE-2023-44487）
2023年に確認されたHTTP/2のDoS手法。リクエストを送っては直ちにRST_STREAMで取り消す動作を高速反復し、当時の記録的なDDoS攻撃に用いられた。
HTTP/2 Bomb（CVE-2026-49975）
2026年6月に公表されたDoS手法の通称。HPACKの参照による増幅とフロー制御の停滞を組み合わせ、短時間で大量のメモリを占有する。CVEの公式記述はmod_http2における過大なメモリ確保によるDoSとして整理されている。
CVE / CVSS
CVEは公開された脆弱性を一意に識別するための共通ID体系、CVSSはその深刻度を0〜10で表す評価指標である。7.0〜8.9がHIGH、9.0以上はCRITICALに区分される。
協調的開示（Coordinated Disclosure）
発見者が公表前に関係ベンダーへ通知し、修正の準備期間を設けたうえで公開する手順。本件は主要な通知から公開まで72日が置かれた。
「Unknown」ステータス
CERT/CCのベンダー一覧における第三の区分。Known AffectedにもKnown Not Affectedにも分類されていない、すなわちCERT/CCの公開記録上は影響の有無が確定していないことを意味する。安全の証明ではないが、各社内部に情報がないことを示すものでもない。今回は118社中89社がこれに該当する。
CERT Addendum
CERT/CCが各ベンダー欄に付す補足注記。ベンダーからの正式な声明がない場合でも、どのCVEが該当するかをここで示すことがある。ベンダーステータス表の表示とずれる場合があるため、CVEと製品の対応を追う際はAddendumと公式アドバイザリを優先して照合する。
Http2SmallWndTimeout
NetScalerの修正版で新設された設定項目。受信窓が小さいまま停滞したストリームを打ち切るまでの秒数を指定する。HTTP Strict Profilesでは初期値30秒、それ以外の構成では0（無効）となる。
TMM（Traffic Management Microkernel）
F5のBIG-IPでトラフィック処理を担う中核プロセス。メモリを消費し尽くすと再起動が発生する。HA構成ではフェイルオーバーにより利用者への影響が軽減される場合がある。
PoC（Proof of Concept）
脆弱性が実際に成立することを示す検証用コード。ベンダーはこれを使って再現性を確認し、影響の有無を判断する。本件ではGitHubがPoCによる再現を試み、影響を確認できなかったと回答している。
【参考リンク】
CERT/CC Vulnerability Note VU#885548（外部）
本件の一次情報にあたる公式ページ。118社分のベンダー回答が個別に掲載され、影響の有無を自社の実装ごとに確認できる。
RFC 9113 — HTTP/2（IETF Datatracker）（外部）
HTTP/2の現行仕様書。フロー制御やストリーム上限の定義に加え、REFUSED_STREAMの用法など実装者向けのDoS対策も記されている。
RFC 7541 — HPACK: Header Compression for HTTP/2（外部）
HTTP/2のヘッダー圧縮方式HPACKの仕様書。静的・動的テーブルとインデックス参照の仕組みが定義されている。
Apache Traffic Server（外部）
Apacheソフトウェア財団が開発するプロキシ・キャッシュサーバーの公式サイト。修正版9.2.14および10.1.3のリリース情報を掲載する。
NetScaler ADC / Gateway セキュリティ速報 CTX696604（外部）
2026年6月30日公開の公式速報。CVE-2026-13474を含む6件を扱い、パッチ適用後に必要なHttp2SmallWndTimeoutの設定手順を示している。
K000162231: BIG-IP HTTP/2 vulnerability CVE-2026-59762（外部）
F5の公式アドバイザリ。HTTP/2プロファイル設定時のメモリ増大と、修正が導入されたバージョンおよび対象製品系列を案内している。
NVD — CVE-2026-59762 詳細（外部）
米国国立標準技術研究所が運営する脆弱性データベースの該当ページ。CVSS 3.1と4.0の双方のスコアと評価ベクトルを確認できる。
BIND 9 Issue #5948（ISC GitLab）（外部）
BINDの開発元による検証記録。影響なしと判断した根拠となる、試験条件と接続あたりのメモリ実測値が公開されている。
CERT/CC VU#605641 — HTTP/2 実装のDoS脆弱性群（2019年）（外部）
Data Dribbleを含む2019年のHTTP/2脆弱性群をまとめたNote。今回の問題と原理を共有する先行事例を確認できる。
Okta Security（外部）
今回の報告者であるOkta Red Teamを擁する、同社セキュリティ部門の公開ページ。脆弱性開示に対する方針が記されている。
【参考記事】
Denial-of-service vulnerability in HTTP/2 servers via stalled flow-control conditions（外部）
本件の一次情報。7月16日公開、7月23日最終更新。CSAF形式の公開データで確認すると、通知先118社の内訳は影響あり7社、影響なし22社、未確定89社。Fastlyはh2o実装でバッファ上限がSIZE_MAXの場合に成立すると説明し、ISCは64KB応答・100並列という条件下でBINDの接続あたりピークメモリを約1.6MBと実測した。各欄のCERT Addendumから、CVE-2026-44909がMetaのProxygen、CVE-2026-59173がApache Traffic Serverに対応することも読み取れる。
CVE-2026-59762 Detail（NVD）（外部）
F5が採番したCVEの公式記録。CVSS 3.1で7.5（HIGH）、CVSS 4.0で8.7。仮想サーバーにHTTP/2プロファイルが設定されている場合にメモリ利用が増加し、TMMプロセスの再起動を伴うサービス妨害に至り得るとする。修正境界は17.1.3.4 / 17.5.1.8 / 21.0.0.3 / 21.1.0.1。
NetScaler ADC and NetScaler Gateway Security Bulletin（CTX696604）（外部）
2026年6月30日公開の公式速報。VU#885548の挙動をCVE-2026-13474として扱い、同CVE向けのコード変更で解消したと説明する。6件のうちCVE-2026-8451、8452、8655の3件がCVSS v4で8.8。非Strict構成では初期値0のHttp2SmallWndTimeoutを手動で30秒に設定するよう指示している。
Apache Traffic Server セキュリティアドバイザリ（外部）
CVE-2026-59173に関するプロジェクト側の告知。9.2.14および10.1.3への更新と、上限超過ストリームをREFUSED_STREAMで拒否する変更を示している。
March 2026 Security Releases（Node.js）（外部）
2026年3月24日のセキュリティリリース。接続レベルのWINDOW_UPDATEでフロー制御窓が上限を超えた際、GOAWAY送出後もHttp2Sessionが解放されないメモリリーク（CVE-2026-21714）を公表している。
Apache HTTP Server 2.4 vulnerabilities（外部）
公式の脆弱性一覧。2026年5月のmod_http2における二重解放（CVE-2026-23918、2.4.67で修正）と、6月のHTTP/2 Bomb（CVE-2026-49975）の双方が掲載されており、HTTP/2実装の問題が連続している状況を一次資料で確認できる。
HTTP/2 Rapid Reset: deconstructing the record-breaking attack（外部）
2023年のCVE-2023-44487に関するCloudflareの公式解説。リクエスト送信直後のRST_STREAMを高速反復する手法と、当時の記録的な秒間リクエスト数を報告している。今回の攻撃との性質の違いを確認する基準となる。
HTTP/2 Bomb DoS Attack: Memory Exhaustion Threat Explained（外部）
2026年6月に公表されたHTTP/2 Bombの技術解説。HPACKの増幅とフロー制御の停滞を組み合わせ、単一クライアントが短時間で大規模なメモリを消費し得ると報告する。研究者による攻撃名とCVEの公式記述は区別して読む必要がある。
