Webセキュリティ 2026.07.27

【AI時代のWeb防御】AIが発見した脆弱性HTTP/2 Bombとは？

DDoS
WAF

3行で分かる本記事のサマリ

HTTP/2 Bombは、HTTP/2の仕組みを悪用してWebサーバーのメモリを急速に消費させるDoS攻撃です。
公開情報では、AIコーディングエージェントであるCodexを使って発見された事例として紹介されており、PoCも公開されています。
AI時代には未知・新種のWeb脆弱性がより早く発見・再現される可能性があり、外部公開Webサーバーには防御の見直しが求められます。

はじめに

WebサーバーやWebアプリケーションは、企業のサービス提供や顧客接点を支える重要な基盤です。一方で、インターネットに公開されている以上、世界中の攻撃者から直接アクセスされる可能性があります。
近年、AIの進化により、ソースコードの解析、脆弱性の発見、攻撃手法の組み合わせが以前よりも高速化する可能性が指摘されています。その象徴的な事例の一つとして注目されたのが、HTTP/2 Bombです。
HTTP/2 Bombは、Web通信で広く使われるHTTP/2の仕組みを悪用し、サーバーのメモリを急速に消費させることでサービス停止を引き起こす可能性のある攻撃です。公開情報では、OpenAI Codexを活用して発見されたと説明されており、さらにPoCも公開されています。
本記事では、HTTP/2 Bombの概要、攻撃の仕組み、そして外部公開Webサーバーに求められるフロンティアAI対策について分かりやすく解説します。

1．HTTP/2 Bombの概要

HTTP/2 Bombとは、HTTP/2通信の仕組みを悪用して、Webサーバーのメモリを大量に消費させるサービス拒否、つまりDoS攻撃の一種です。
DoS攻撃とは、サーバーに過剰な負荷をかけ、正常な利用者がWebサイトやWebサービスにアクセスできない状態にする攻撃です。情報を盗む攻撃とは異なり、主な被害は「サービス停止」や「応答遅延」です。
HTTP/2 Bombが注目された理由は大きく3つあります。

HTTP/2 Bombが注目された理由

①少量の攻撃通信によって、サーバー側に大きな負荷を与えられること

一般的な大量アクセス型のDDoS攻撃では、攻撃側にも多くの通信量が必要になります。
一方、公開情報によると、HTTP/2 Bombは1台の端末と一般的な回線でも、短時間でサーバーを応答不能にし得ると説明されています。
つまり、大規模な攻撃基盤を持たない攻撃者でも、条件が合えば深刻な影響を与えられる点が危険視されています。

②PoCが公開されていること

PoCとはProof of Conceptの略で、脆弱性が実際に成立することを示す実証コードを指します。
PoCは、防御側が影響確認や対策検証を行ううえで重要な情報です。一方で、攻撃者にとっても攻撃手法を理解し、再現しやすくなる材料になり得るため、早期に影響確認と防御策の見直しを行うことが重要です。

③AIを活用して発見された脆弱性であること

HTTP/2 Bombは、AIコーディングエージェントであるOpenAI Codexを活用して発見された攻撃手法として、公開情報では説明されています。
具体的には、以前から知られていた複数の攻撃手法を組み合わせる形で発見されたとされています。これは、AIが既知の技術情報やコードの差分を分析し、これまで見落とされていた攻撃の組み合わせを見つける可能性を示す事例です。
つまり、HTTP/2 Bombは「AIによる脆弱性発見」が、将来の話ではなく、現実のWebセキュリティ課題として表面化したということです。

2．HTTP/2 Bombの攻撃の仕組み

HTTP/2 Bombの仕組みを、簡単にご紹介します。

悪用されたHTTP/2の仕組み「ヘッダー圧縮」とは

ブラウザがWebサイトにアクセスするとき、ブラウザからサーバーへは「ヘッダー」と呼ばれる付随情報が送られます。
ヘッダーには、たとえば「どのページを見たいのか」「どんなブラウザを使っているのか」「ログイン情報やCookieはあるか」といった情報が含まれます。

HTTP/2は、Webサイトを高速に表示するために使われる通信方式です。HTTP/2では、こうしたヘッダー情報を短い情報でやり取りできるように工夫されています。
たとえるなら、飲食店で「ハンバーグ、ライス、サラダ、スープ、ドリンクのセット」と長く伝える代わりに、「Aセット」とだけ注文するようなものです。
注文する側は短い言葉で済みますが、お店側は「Aセット」が何を含むのかを確認し、実際にハンバーグ、ライス、サラダ、スープ、ドリンクを準備する必要があります。
HTTP/2のヘッダー圧縮もこれに近く、通信する側は短い情報で済みますが、サーバー側ではその情報をもとに実際の内容を確認し、処理する必要があります。
通常であれば、これは通信を効率化し、Webサイトを速く表示するための便利な仕組みです。
ヘッダ圧縮.png

HTTP/2 Bombでは、この仕組みが悪用される

「ヘッダー圧縮」は、本来であれば通信を速くするための便利な機能です。
しかし、HTTP/2 Bombでは、この仕組みが悪用されます。

攻撃者は、ネットワーク上では小さく見える情報を繰り返しサーバーに送ります。
サーバー側では、その大量の短い情報を確認し、処理のためにメモリを使います。
その結果、攻撃者が送るデータ量は小さくても、サーバー内部では処理が大きく膨らみ、想定以上のメモリが使われてしまう場合があります。

また、HTTP/2 Bombでは、単に小さな通信を繰り返し送り大きな処理を発生させるだけではありません。
攻撃者は、通信をすぐに終わらせず、サーバーに「まだ処理中」の状態を保たせます。
これにより、サーバーは使ったメモリをすぐに解放できず、メモリ使用量が増え続けます。

先ほどのレストランの例でいえば、料理の完成後、攻撃者は料理の受け取り拒否をします。
そうすると、レストラン側は料理や配膳スペースを片付けられません。
その結果、厨房や店内の余裕がなくなり、ほかのお客さんへの対応が難しくなっていきます。

攻撃の流れまとめ

攻撃の流れを簡単にまとめると、次のようになります。

攻撃者が、サーバー側の処理を膨らませる短い情報を繰り返しサーバーに送る
サーバー側では、繰り返し送られる短い情報を処理するために大きなメモリが使われる
攻撃者が通信を終わらせず、サーバーに処理中の状態を保たせる
メモリが次第に圧迫され、応答遅延やサービス停止につながる

ポイントは、攻撃者が大量のデータを送りつけなくても、サーバー側に大きな負荷を発生させられることです。
つまりHTTP/2 Bombは、HTTP/2の「少ない通信量で効率よくやり取りする仕組み」を逆手に取り、サーバー内部の処理負荷を大きく膨らませる攻撃だと言えます。

3．外部公開 Web サーバーに求められるフロンティアAI対策

基本的な対策は、セキュリティパッチの適用・アップデート

HTTP/2 BombのようなWeb脆弱性に対して、まず基本となる対策は、影響を受けるソフトウェアを確認し、必要に応じて修正済みバージョンへアップデートすることです。
Webサーバー、リバースプロキシ、APIゲートウェイ、ロードバランサーなど、外部公開されたWeb基盤でHTTP/2を利用している場合は、利用している製品やバージョンが脆弱性の影響を受けるかを確認する必要があります。
そのうえで、ベンダーから提供されるセキュリティパッチの適用・アップデートをすることが重要です。

アップデートだけに頼らない備えが必要

しかし、実際の企業システムでは、すべての脆弱性に対して即座にアップデートを適用できるとは限りません。
Webサービスを停止できる時間は限られており、アップデート前には影響確認、検証、メンテナンス調整、関係者への通知などが必要になります。
特に今後、AIによる脆弱性発見が進むことで、新たなWeb脆弱性がより短い間隔で見つかる可能性があります。
そのたびに本番環境のメンテナンス時間を確保し、すべてのシステムを即座に更新し続けることは、現実的には大きな負担になります。

また、ソフトウェアアップデートは、すでに発見され、修正プログラムが提供された脆弱性に対して有効な対策が、まだ発見されていない未知の脆弱性や、修正プログラムが提供される前の攻撃に対しては、アップデートだけで防ぐことはできません。
つまり、アップデートは非常に重要な対策ですが、それだけで外部公開Webサーバーを十分に守れるとは限らないのです。

4．攻撃を到着する前に検知・防御する防御総：WAF

そこで有効な対策の一つとなるのが、WAF（Web Application Firewall）です。
WAFは、Webアプリケーションとインターネットの間で通信を監視・制御し、不審なリクエストを検知・遮断するセキュリティ製品です。攻撃をWebアプリケーション本体に到達させる前に制御できる点が、大きな特長です。
たとえば、異常なリクエスト、大量アクセス、不自然なヘッダー、通常とは異なる通信パターンなどを検知し、必要に応じてブロックや制限を行うことができます。

修正までの時間を補う「仮想パッチ」

また、WAFは「仮想パッチ」として機能する場合もあります。仮想パッチとは、ソフトウェア自体をすぐに修正できない場合でも、WAF側で攻撃に使われるリクエストの特徴を検知・遮断し、脆弱性を悪用されるリスクを低減する考え方です。
新しいWeb脆弱性が発見されても、本番環境のアップデートには検証やメンテナンス調整が必要です。そのような場面で、WAFに防御ルールやシグネチャを適用することで、修正プログラムを適用するまでの間、攻撃リスクを抑えることが期待できます。

未知・未修正の脆弱性にも備えるWAF

AIによって未知・新種の脆弱性がより早く発見され、PoC公開によって攻撃手法が短期間で広がる可能性がある中、企業側にも迅速な防御対応が求められます。
WAFは、ソフトウェアアップデートだけでは埋めきれない時間的なギャップを補い、外部公開Webサーバーを守るための有力な防御手段となります。
特に、既知の脆弱性に対する防御だけでなく、未知の脆弱性が悪用される場合でも、不審なリクエストや通常とは異なる通信パターンを検知・制御することで、攻撃リスクを低減できる可能性があります。

重要なのは「検知できる」だけでなく「止められる」こと

そのため、AI時代のWebセキュリティにおいては、最新の脆弱性へ迅速に追随できることに加え、未知の攻撃にも備えられる検知精度が重要です。
さらに、実運用では「検知できること」だけでなく、「ブロックモードで運用しやすいこと」も欠かせません。
誤検知が多いWAFでは、正常な利用者への影響を懸念して、実際にはブロック運用に踏み切りづらくなります。
そのため、ブロックモードで運用しやすい誤検知の少なさや、日々の運用を支援する機能を備えたWAFを選定・運用することが重要です。

5．Imperva Cloud WAFについて

弊社で取り扱うThales社「Imperva Cloud WAF」は、最新の脆弱性や攻撃手法に対応するための防御ルールが継続的にアップデートされるクラウド型WAFです。

未知・新種の攻撃にも備える

Imperva Cloud WAFは、既知の攻撃パターンだけでなく、不審なリクエストや通常とは異なる通信挙動を検知・制御することで、未知・新種の攻撃に対しても一定の防御効果が期待できます。
AIによって新たなWeb脆弱性の発見や攻撃手法の拡散が加速する可能性がある中で、こうした未知・新種の攻撃にも備えられる点は大きな価値となります。

ブロックモードで運用しやすい検知精度

また、検知精度の高さにより、正規の通信をできるだけ妨げずに攻撃通信をブロックしやすい点も特長です。
これにより、「誤検知が怖くてブロックモードにできない」「検知モードのまま放置されてしまう」といった状態に陥りにくく、実効性のあるWAF運用を進めやすくなります。

日々の運用負荷を軽減

さらに、運用支援機能が充実している点も重要です。
WAFアラートを集約する機能により、攻撃の全体像を把握しやすくし、管理者の確認負荷を軽減します。
加えて、アラート状況に応じた設定の最適化をサジェストする機能もあり、継続的なチューニングにも対応しやすくなります。

6．まとめ

HTTP/2 Bombは、HTTP/2の効率的な通信の仕組みを悪用し、少ない攻撃通信でもサーバー側に大きな負荷を発生させる可能性があるDoS攻撃です。AIを活用して発見された攻撃手法として紹介され、PoCも公開されていることから、防御側には早期の影響確認と対策の見直しが求められます。

この事例は、AI時代においてWeb脆弱性の発見や攻撃手法の再現が、これまで以上に速く進む可能性を示しています。もちろん、影響を受けるソフトウェアのアップデートは基本対策です。しかし、すべての脆弱性に即座に対応することは難しく、未知の脆弱性や修正プログラム提供前の攻撃には、アップデートだけでは十分に備えられない場合があります。

そのため、今後のWebセキュリティでは、攻撃をWebサーバーやアプリケーション本体に到達させる前に検知・制御する防御層であるWAFの活用が重要です。

Imperva Cloud WAFは、最新脆弱性への迅速な対応、ブロックモードでの運用のしやすさ、アラート集約や設定最適化による運用負荷の軽減を支援するクラウド型WAFです。HTTP/2 Bombのような新たなWeb脆弱性に備えるうえで、外部公開WebサーバーやWebアプリケーションの防御強化を検討する有効な選択肢となります。