AIが発見『HTTP/2 Bomb』CVE-2026-49975、Webサーバを数秒で停止

自宅にある普通のパソコン1台から、世界の主要なWebサーバをわずか数秒で応答不能に追い込める弱点（情報セキュリティ上の欠陥）が見つかりました。「HTTP/2 Bomb」と名付けられたこの欠陥は、共通の管理番号CVE-2026-49975として整理され、世界で最も使われているWebサーバの一つApache HTTP Serverでは、2026年6月8日に公開された修正版2.4.68で塞がれました。日本でも同日、JPCERT/CCの脆弱性情報ポータルJVN（JVNVU#99913823）を通じて注意喚起が出ています。

驚かれるのは見つけ方かもしれません。この欠陥は、人間の研究者ではなくOpenAIのAI「Codex」が、10年以上前から知られていた2つの手口を組み合わせる形で先に気づいたものです。攻撃を再現する実証コード（PoC）はすでに公開され、発見元の調査ではインターネット上に88万台以上のサーバが無防備にさらされているとされています。影響はApacheだけにとどまらず、nginx・Microsoft IIS・Envoyなど、HTTP/2という通信方式を使う主要なWebサーバ全体に広がる横断的な問題です。

この記事では、HTTP/2 Bombとは何が起きる弱点なのか、なぜAIが人より先に見つけられたのか、Apache 2.4.68で同時に直った他の脆弱性も含めて自分のサーバが何を直すべきなのか、そしていま何をすればいいのかを、専門知識がなくてもわかるように整理します。なお本件は情報を盗むタイプではなく、サービスを止めるタイプの攻撃です。

どのバージョンが対象で、どう更新すればいいのか

まず結論です。Apache HTTP Serverでは、HTTP/2を扱う部品（mod_http2）を含む2.4.17から2.4.67までのすべてのバージョンがHTTP/2 Bombの対象で、2.4.68に更新すれば塞げます。さらにこの2.4.68は、HTTP/2 Bomb（CVE-2026-49975）を含め合計13件の脆弱性をまとめて修正したリリースでもあります。自分の使っているバージョンは、サーバ上で httpd -v や apache2 -v を実行すると確認できます。

多くの企業や個人は、OS（Ubuntu・Debian・RHEL等のLinux）が配るパッケージ経由でApacheを使っています。その場合は、各ディストリビューション（Linuxの配布元）が修正を取り込んだ更新を出すので、apt や dnf による通常のアップデートで適用できます。すぐに更新できない事情がある場合の応急策（HTTP/2を一時的に無効にするなど）は後述します。なお、いまHTTP/2を使っていない設定であれば、HTTP/2 Bombの直接の影響は受けません。

何が起きるのか。1台の家庭用PCが大規模サーバを数秒で黙らせる

HTTP/2は、Webページを速く表示するために2015年に標準化された新しい通信方式で、いまでは多くのサイトが使っています。HTTP/2 Bombは、この方式に備わった2つの仕組みを悪用して、サーバのメモリを一気に食い尽くし、応答できない状態に追い込む攻撃です。情報の漏えいや乗っ取り（コード実行）ではなく、サービスそのものを止める「サービス妨害（DoS）」にあたります。技術的な分類は「過大なサイズのメモリ確保（CWE-789）」です。

怖いのはその効率です。発見元のCalif.ioの解説によると、100Mbpsの一般的な回線につないだ家庭用パソコン1台で、対象サーバを数秒のうちに応答不能にできるとされています。攻撃側はわずかな通信量しか送らないのに、受け取ったサーバ側では1バイトあたり最大数千バイトものメモリが膨れ上がり、1つの接続だけで32GBものメモリを10〜45秒で消費させられる、という実験結果が示されています。攻撃にログイン（認証）は不要で、外からHTTP/2でつながれるサーバなら誰でも標的になり得ます。

仕組みは、長年知られていた2つの古典的な手口の組み合わせです。1つ目は「HPACK」というヘッダー圧縮の仕組みを悪用するもので、最初に1個だけ大きなヘッダーをサーバの一時表に覚え込ませ、あとは「さっきのヘッダーをもう一度」という1バイトの指示を何千回も送ると、サーバ側は毎回それを大きなデータとして展開してしまいます。2つ目は通信量を調整する「フロー制御」の悪用で、攻撃者が「もう受け取れない」とサーバに告げて応答の完了をわざと止め、メモリを抱え込んだまま離さない状態を作ります。この2つを重ねると、わずかな送信で大量のメモリを長時間つかんだままにでき、サーバが力尽きます。

この穴を、どんな人が、何のために狙うのか

「データが盗まれないなら大したことはない」と感じるかもしれません。けれど、この欠陥が突くのは情報ではなく、サイトやサービスが当たり前に動いているという事実そのものです。安い回線1本で大手のサーバを落とせるという手軽さは、特定の人々にとって極めて魅力的に映ります。狙ってくるのは、サイトを人質にして金銭を要求するDoS脅迫の常習犯、競合の販売機会や予約をピーク時に潰したい同業者、主張のために標的サイトを黙らせたいハクティビスト、そして本命の侵入や情報窃取から目をそらすために一時的に監視やサービスを止めたい侵入者です。彼らが奪うのは中身ではなく、利用者がサイトにアクセスできる時間のほうです。HTTP/2 Bombのリクエストを送り込まれた瞬間、その日いちばんアクセスが集まる時間帯にこそ、サイトは黙って使えなくされてしまいます。

被害はサーバ1台の停止では終わりません。ネット通販なら注文が入らず、予約サイトなら受付が止まり、業務システムなら社内外の作業が一斉に滞ります。さらに厄介なのは、サービス停止の対応に運用担当者の人手と注意が吸い取られている隙を突いて、本命のランサムウェアや不正アクセスを仕掛ける「陽動」として使われるパターンです。落ちている数十分のあいだに、監視の目が手薄になった別の入口から本格的な攻撃が進む、という流れは現実に起きています。

そして、止まったサービスの損失と後始末を背負うのは、そのサイトやサーバを運用する事業者・情報システム部門です。売上の機会損失、利用者への謝罪と問い合わせ対応、原因調査と復旧、取引先との約束（SLA）の不履行、そして「なぜ更新を後回しにしたのか」という説明責任までがのしかかります。Apacheの評価ラベルは最高位ではなく「中程度（Moderate）」ですが、安価な手段で・認証もなく・実証コードまで公開されているという条件がそろっている以上、ラベルの低さは「急がなくてよい理由」にはなりません。更新が出たいま当てられるかどうかが、止められる側になるかどうかの分かれ目です。

なぜAIが人より先に見つけられたのか

この一件で世界の技術者が注目したのは、欠陥そのものよりも「見つけたのがAIだった」点です。発見の決め手になった2つの手口——ヘッダー圧縮の悪用と、フロー制御による応答の引き延ばし——は、どちらも10年以上前から個別には知られていたものでした。OpenAIのコーディング支援AI「Codex」が見抜いたのは、その2つを組み合わせると桁違いの破壊力になるという一点です。発見元は「組み合わせを見れば当たり前なのに、私たちの知る限り誰もそれを一つにまとめていなかった」と振り返っています。

これは、AIがゼロから未知の理論を生み出したというより、人間が見落としていた既知の部品の組み合わせを、膨大な前例を踏まえて素早くつなげた、という話です。とはいえ意味は小さくありません。脆弱性の発見は今後、AIによって速度と量が大きく変わる可能性があり、攻撃側がそれを使えば、見過ごされてきた古い仕組みの組み合わせが次々と武器化されていく恐れがあります。同じくAIをめぐる攻防は、攻撃と防御の両面で加速しています。今回は防御側（発見・修正）にAIが働いた好例ですが、その逆も十分に起こりうる、という警鐘でもあります。

Apacheだけではない。主要Webサーバの対応状況

HTTP/2 Bombは、特定の製品のバグというより、HTTP/2という方式の実装に共通して潜んでいた弱点です。そのため、影響は主要なWebサーバを横断しました。発見元の調整を受けて、各製品が時期をずらして対応しています。下の表に、公開時点までに分かっている対応状況を整理します。

つまり「Apacheさえ直せば終わり」ではなく、自社がnginxやリバースプロキシ、ロードバランサ、クラウドの前段で何を使っているかを棚卸しして、それぞれの最新情報を確認する必要があります。Apacheは世界のWebサーバの2割超を占め、HTTP/2は事実上の標準として広く使われているため、影響を受ける構成は珍しくありません。

2.4.68では他に12件も直っている。自分が踏むのはどれか

今回のApache 2.4.68は、HTTP/2 Bomb以外にも12件の脆弱性をまとめて修正しています。いずれもApacheの評価は中程度（Moderate）か低（Low）で、サーバを乗っ取られるような重大なものは含まれていませんが、使っている機能によっては自分に関係するものがあります。代表的なものを挙げると、共有レンタルサーバの利用者が知っておきたいのがCVE-2026-44119です。これは、サイトごとの設定ファイル（.htaccess）に細工を書ける立場の人が、本来見えないはずの他の利用者のファイルを読み取れてしまう権限昇格の欠陥で、1台のサーバを複数人で共有するレンタルサーバ事業者には特に重要です。

そのほか、リバースプロキシ機能（mod_proxy系）で悪意あるバックエンドの応答を処理する際のメモリ破壊（CVE-2026-34355など）、SSL証明書の確認処理での情報漏えい（CVE-2026-44185）など、特定の構成でのみ影響するものが並びます。すべての詳細はApache公式の脆弱性一覧にまとまっています。細かく切り分ける時間がなくても、結論は同じで「2.4.68へ更新すれば13件すべて塞げる」です。自分の構成を細かく確認するより、まず最新版に上げるのが確実でございます。

公開から修正までの流れ

HTTP/2 Bombは、複数のWebサーバにまたがるため、各製品の準備を待ちながら段階的に公表されました。Apache向けの修正がApache HTTP Server 2.4.68として正式に出そろったのが6月8日です。時系列で整理します。

← スワイプで移動

いまの危険度をどう見るか

冷静に整理すると、起きるのは「サービスの停止」であって情報の漏えいやサーバの乗っ取りではなく、まだ広範な悪用も確認されていません。一方で、無認証で・安価な手段で・実証コード付きで・88万台が露出しているという条件は、攻撃のハードルが極めて低いことを意味します。悪用が始まってから慌てるより、修正版が出そろったいま当ててしまうのが、最も安く確実な選択です。

いま何をすればいいのか

Webサーバを運用している場合にやるべきことは、更新が中心です。手順は次のとおりです。

• Apacheのバージョンを確認し（httpd -v / apache2 -v）、2.4.68より前なら対象と判断する
• OS付属のApacheなら apt / dnf 等で更新する。各ディストリビューションが修正を取り込んだ版を確認する
• すぐに更新できない場合の応急策として、不要ならHTTP/2を一時的に無効にする、または1接続あたりのヘッダー数・メモリ使用を制限する設定を検討する
• nginxやリバースプロキシ、ロードバランサ、クラウドの前段で使っているソフトも棚卸しし、それぞれの最新情報を確認する
• サーバのメモリ急増や応答遅延を監視し、急なメモリ枯渇の兆候がないかログとリソース監視を強化する

特に、インターネットに直接面したWebサーバや、HTTP/2を有効にした公開サイトを運用している場合は、優先度を上げて対応してください。今回の攻撃は外から到達できるHTTP/2の口に細工した通信を送るだけで成立するため、公開状態を放置するほどリスクが高まります。複数台のサーバを運用している場合は、棚卸しのうえで一括して更新を進めるのが確実です。

よくある質問

まとめ

CVE-2026-49975「HTTP/2 Bomb」は、安価な回線につないだ家庭用パソコン1台でも、Apacheをはじめとする主要なWebサーバを数秒で応答不能に追い込めるサービス妨害の脆弱性です。情報の窃取や乗っ取りではありませんが、認証なしで・少ない通信量で・実証コード付きという条件がそろい、発見元はインターネット上に88万台超が露出していると報告しています。Apacheは2026年6月8日公開の2.4.68で、HTTP/2 Bombを含む13件をまとめて修正しました。

この一件は、10年以上知られていた2つの手口を組み合わせると危険になることに、人間ではなくAIが先に気づいたという点でも注目されました。脆弱性の発見が速く・多くなる時代に入ったことを示す出来事でもあります。Webサーバを運用している人は、バージョンを確認して2.4.68以降へ更新し、nginxやプロキシなど前段のソフトもあわせて点検してください。情報が漏れないからと後回しにするには、攻撃のハードルが低すぎる一件でございます。

参照元

• ▸JVN - JVNVU#99913823（Apache HTTP Server 2.4における複数の脆弱性に対するアップデート）
• ▸Apache HTTP Server 2.4 脆弱性一覧（Fixed in 2.4.68）
• ▸NVD - CVE-2026-49975
• ▸Calif.io - Codex discovered a hidden HTTP/2 Bomb（発見元の技術解説）
• ▸oss-sec メーリングリスト - CVE-2026-49975 開示
• ▸CWE-789: Memory Allocation with Excessive Size Value
• ▸W3Techs - Apache の利用シェア