この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
OpenAIのCodexが、10年以上前から知られていた2つの古い手口を組み合わせて掘り当てた、HTTP/2のメモリ枯渇型DoSです。通称は「HTTP/2 Bomb」、Apache httpd向けにCVE-2026-49975が割り当てられています。nginx・Apache httpd・IIS・Envoy・Cloudflare Pingoraと、HTTP/2をデフォルトで有効にしている主要サーバーが軒並み対象に挙がっています。
この記事では、HTTP/2 Bombとは何なのか、その技術的な本質はどこにあるのか、そして現役のLinuxサーバー管理者として自分の環境をどう確認し、何から手を打てばいいのかを整理します。
この記事のポイント
・OpenAIのCodexが既知の2手法を合成して見つけたHTTP/2のメモリ枯渇型DoS（通称HTTP/2 Bomb、CVE-2026-49975）
・以前報じた二重解放のCVE-2026-23918とは別件。手口も影響も異なる
・nginxは1.29.8で修正済み。Apache 2.4系はまだ未パッチで、設定での緩和が現実解
・自サーバーのHTTP/2有効・無効の確認と、ヘッダ数制限・HTTP/2無効化などの暫定対応を解説
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
HTTP/2 Bombとは何か：CVE-2026-49975の概要
HTTP/2 Bombは、HTTP/2をデフォルト構成で有効にしているWebサーバーに対して、単一のクライアントからメモリを枯渇させてサービスを停止に追い込むDoS（サービス妨害）の手口です。Apache httpd向けにCVE-2026-49975が割り当てられています。
セキュリティ企業Califが一次情報を公開し、ITmediaなどでも報じられました。攻撃の前提が軽いのが特徴で、100Mbps程度の回線に家庭用PCクラスの1台があれば成立するとされています。認証も特別な権限も要りません。Califのベンチマークでは、Apache httpd 2.4.67が約18秒で約32GBを、Envoy 1.37.2が約10秒で約32GBを使い切ったと報告されています。報道で目にする「約20秒で32GB」は、この両者を丸めた代表値です。
ここで先に、ひとつ混同を避けておきます。少し前に当サイトでも取り上げた、Apache HTTP/2の二重解放（Double Free）の脆弱性CVE-2026-23918とは別件です。あちらはHEADERS直後のRST_STREAMでクリーンアップが二重に走るメモリ破壊系のバグで、修正はhttpd 2.4.67でした。今回のHTTP/2 Bombはメモリを食い潰すリソース枯渇型で、機序も対象製品も修正の状況もまったく違います。「2.4.67に上げたから今回のも大丈夫」と早合点しないよう、最初に押さえておいてください。
なお現時点で、CVE-2026-49975はNVD（National Vulnerability Database）ではまだRESERVED段階で、詳細分析が公開されていません。CVSSの公式スコアも確定していないため、本記事でも「深刻度はいくつ」という断定は避けます。番号自体は複数の情報源で一致しているので、確からしさは高いという位置づけで読み進めてください。
一次情報の整理：Codexが「古い手口の組み合わせ」を見つけた
今回いちばんニュースとして大きいのは、この脆弱性を見つけたのがOpenAIのCodexだという点です。Califの一次情報によれば、Codexがnginxなどのコードベースを読み込み、長年知られてきた2つの攻撃手法が組み合わせられることに気づいて、連鎖させた攻撃を構築した、という経緯になっています。
注意したいのは、Codexがゼロから未知の概念を発明したわけではない、という点です。素材になったのは、HPACK圧縮を悪用したいわゆる圧縮爆弾系と、Slowlorisに代表されるフロー制御を引き伸ばす滞留系という、どちらも10年以上前から人間に知られていた古い手口でした。それぞれ単体では既知で、対策も語られてきたものです。Codexがやったのは、その2つを新しい形でチェーンさせ、片方では発火しない上限チェックをすり抜ける組み合わせを見つけ出したことです。
つまり「個々のパーツは枯れているのに、つなげ方が新しい」という発見でした。膨大なコードと既知の攻撃パターンを突き合わせて、人間が見落としていた合成を拾い上げる——この作業はAIが得意とするところで、今回の出来事が示す意味はそこにあります。
技術的な本質：HPACK参照爆弾とゼロウィンドウ滞留の合わせ技
では中身を見ていきます。HTTP/2 Bombは、大きく2つの仕掛けを組み合わせています。
1つ目が、HPACKのインデックス参照爆弾です。HTTP/2はヘッダ圧縮にHPACKを使い、一度送ったヘッダを動的テーブルに登録して、以降は短いインデックス参照で呼び出せる仕組みを持っています。攻撃者はまず大きめのヘッダを1つ動的テーブルに仕込み、それを指すわずか1バイトのインデックス参照を数千回送りつけます。攻撃側のコストはワイヤ上で1参照あたり1バイト程度と極端に小さい一方、サーバー側は1参照を展開するたびに数十バイトから数千バイト規模のメモリを確保します。やっかいなのは、デコード後の中身が実質ほぼ無いため、デコード後サイズの上限チェックが発火せずにすり抜けてしまう点です。
2つ目が、HTTP/2のウィンドウ滞留です。HTTP/2にはフロー制御があり、受信側が「これ以上は受け取れる/受け取れない」をウィンドウサイズで広告します。攻撃者はこのウィンドウをゼロバイトに広告し、サーバーがレスポンスを送り切れない状態を作ります。そのうえで1バイトのWINDOW_UPDATEフレームをちびちびと送り続け、送信タイムアウトをリセットしながら接続を生かし続けます。こうして、確保したメモリを解放させずにサーバー上へピン留めし続けるわけです。
この2つが合わさると、参照爆弾で大量のメモリを確保させ、ウィンドウ滞留でそれを解放させない、という状態が完成します。1接続あたりの占有が積み上がり、わずかな時間でメモリが底を突く。これがHTTP/2 Bombの正体です。Apache側の修正では、分割して送られたCookieヘッダの断片をLimitRequestFields（リクエストフィールド数の上限）にカウントするよう変えて、断片が上限をすり抜けられないようにした、と説明されています。
PR
HTTP/2のフロー制御やヘッダの扱いは、設定ファイルの意味が腹に落ちていないと緩和策を打っても効きが読めません。本書はnginxの設定・運用・性能・セキュリティを実践目線で網羅していて、今回のようなHTTP/2絡みの挙動を自分のconfと突き合わせて考えたい現役管理者に向いています。
Linux管理者がいま確認・対応すべきこと
ここからが本題です。自分のサーバーが該当するのか、何をすればいいのかを順に見ていきます。
1. まず自サーバーでHTTP/2が有効かを確認する
HTTP/2を使っていなければ、この攻撃の直接の対象にはなりません。curlで自分のサイトに対してHTTP/2のネゴシエーションを試すのが手早い確認方法です。
curl -sI --http2 https://example.com/ | grep -i "^HTTP"
応答の先頭行が「HTTP/2 200」のようにHTTP/2で返ってくれば有効、「HTTP/1.1 200」ならHTTP/2では応答していません。nginxならconfのlistenディレクティブにhttp2が付いているか、Apacheならmod_http2のLoadModuleとProtocols h2 h2cの指定があるかを、設定ファイル側でも確認しておくと確実です。
2. nginxは1.29.8以降へ更新する
nginxは2026年4月の1.29.8で修正済みです。このリリースでヘッダ数に上限を課すmax_headersディレクティブが追加され、参照爆弾でヘッダを大量に積み上げる経路を塞げるようになりました。nginxを使っているなら、まずは1.29.8以降への更新が本筋の対応です。更新前の暫定策としても、ヘッダ数や1接続あたりのリソースを抑える設定を見直しておく価値があります。
3. Apache 2.4系は「未パッチ」前提で緩和策を打つ
ここが今回いちばん注意してほしいところです。Apache側の修正は、スタンドアロンのmod_http2 v2.0.41として提供されています。ところがこの修正は、執筆時点でhttpd 2.4.xブランチにはまだバックポートされていません。つまり、ディストリのパッケージで素のApache 2.4系を動かしている多くの環境は、依然として未修正のままです。繰り返しになりますが、CVE-2026-23918向けの2.4.67に上げても、今回のHTTP/2 Bombは塞がりません。別件だからです。
未パッチの間にできる緩和策としては、研究者やベンダー解説で次のような方向が挙げられています。いずれも公式の暫定アナウンスとして裏が取れたものではないので、自環境で検証のうえ判断してください。
・思い切ってHTTP/2を無効化し、HTTP/1.1にフォールバックさせる（もっとも直接的で確実な暫定策）
・ヘッダ数にハードな上限を課す。Apacheなら LimitRequestFields を絞り込む
・ヘッダ数の上限を強制できるリバースプロキシ・WAF・CDNを前段に置く
・ワーカープロセスにメモリ上限（cgroupのmemory.maxやsystemdのMemoryMax等）を設定し、1接続の暴走でホスト全体が巻き込まれないようにする
HTTP/2無効化はパフォーマンス面のメリットを一時的に手放すことになりますが、メモリ枯渇でサービスごと落ちるリスクと天秤にかければ、パッチが出るまでの保険として十分に現実的な選択です。
4. IIS・Envoy・Cloudflare Pingoraを使っているなら
IISとCloudflare Pingoraは、公開時点でパッチが提供されていないとされています。Envoyについては情報源によって扱いが割れていて、Califの一次情報は「修正リリース済み・検証継続中」とする一方、別の情報源は「公開時点で未修正」としています。Envoyを運用している場合は、公式のGitHub Security Advisoryで最新の状況を直接確認するのが確実です。これらを前段や内部で使っている環境では、ヘッダ数上限やメモリ上限といった緩和策の併用を検討してください。
AIが脆弱性を見つける時代に、現場が備えること
今回の一件は、単なる1つのDoSにとどまらない含みがあります。Codexのような生成AIが、人間が長年見落としてきた「既知の手口の組み合わせ」を拾い上げて、実際に動く攻撃へ仕立てた——この事実そのものが、これからの運用に効いてきます。
古い手口だから、対策済みだから、と片づけてきたものが、新しい組み合わせで蘇る可能性が出てきました。攻撃側がAIで合成を量産できるなら、守る側も「個々の既知脆弱性をパッチしたか」だけでなく、「組み合わせで何が起きうるか」まで視野に入れる必要があります。とはいえ、現場でやることが急に変わるわけではありません。パッチ適用を遅らせない、不要なプロトコルや機能は止めておく、1プロセスの暴走がホスト全体を道連れにしない設計にしておく——こうした基本の積み重ねが、結局いちばん効きます。
私自身、20年以上Linuxサーバーの現場を見てきましたが、派手な新攻撃が出るたびに思うのは、守りの土台は地味な基本の繰り返しだということです。今回のようにAIが攻撃の発見を加速させる時代だからこそ、設定の意味を理解し、自分の手で確認できる力が、より一層ものを言うようになります。
PR
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版（徳丸浩 著／SBクリエイティブ）
攻撃の「仕組み」から逆算して守りを考える視点が、こういう新手の脆弱性に出くわしたときに効きます。通称「徳丸本」と呼ばれる定番で、HTTPの挙動を攻撃者目線で読み解く土台を作ってくれます。サーバー管理者がセキュリティの原理を一度きちんと押さえておきたいときの一冊です。
本記事のまとめ
HTTP/2 Bomb（CVE-2026-49975）は、OpenAIのCodexが既知の2手法を合成して見つけた、メモリ枯渇型のDoSです。HPACKのインデックス参照爆弾で大量のメモリを確保させ、ゼロウィンドウ滞留でそれを解放させない、という合わせ技が本質でした。現役のLinuxサーバー管理者として、まずは自サーバーのHTTP/2有効・無効を確認し、nginxなら1.29.8以降へ更新、Apache 2.4系は未パッチ前提で緩和策を打つ——この順で手を動かすのが現実的です。
| 論点 | 押さえどころ |
|---|---|
| 正体 | HTTP/2のメモリ枯渇型DoS（通称HTTP/2 Bomb、CVE-2026-49975） |
| 機序 | HPACKインデックス参照爆弾＋ゼロウィンドウ滞留の合わせ技 |
| 別件との混同注意 | 二重解放のCVE-2026-23918とは別物。2.4.67では塞がらない |
| nginx | 1.29.8で修正済み（max_headers追加）。更新が本筋 |
| Apache 2.4系 | 未バックポート＝未パッチ。HTTP/2無効化・ヘッダ数制限で緩和 |
| IIS / Pingora / Envoy | IIS・Pingoraは未パッチ。Envoyは情報が割れる（公式advisory要確認） |
正確なCVSS値や影響バージョンの範囲は、NVDへの掲載やApache・各ベンダー公式の勧告が出そろってから確認するのが確実です。それまでは「HTTP/2が有効か」「自分の環境はパッチが来ているか」を自分の手で確認し、来ていないなら緩和策で時間を稼ぐ。地味ですが、これが現場でいちばん効く動き方です。
そのサーバー、「なぜ守れているか」を自分の言葉で説明できますか？
HTTP/2の挙動、ヘッダ数の制限、ワーカーのメモリ上限。新しい攻撃が出るたびに慌てないためには、記事で知識を仕入れるだけでなく、Linuxサーバー上で実際に手を動かして確認できる力が要ります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます