AIが見つけたHTTP/2の死角：数秒でサーバーを停止させる「HTTP/2 Bomb」攻撃とその仕組み

2026年6月8日 H.Ueda

今回は、ウェブサーバーを数秒以内にダウンさせる「HTTP/2 Bomb」攻撃がOpenAIのCodexを使って発見される という記事を参考に、この新しい脆弱性のメカニズムと、なぜこれほどまでに強力なのかを私なりに整理してみました。

HTTP/2への攻撃です。参考まで。

ウェブプロトコルの進化は利便性をもたらしますが、同時に複雑な仕様の組み合わせが予期せぬ脆弱性を生むこともあります。今回発見された「HTTP/2 Bomb」は、まさにその典型例といえるかもしれません。

HTTP/2 Bombとは何か

この攻撃は、一言で言えば「少ないリソースで相手のメモリを食いつぶす」DoS（サービス拒否）攻撃の一種です。驚くべきは、特別な環境が必要なく、ごく普通の家庭用PC（100Mbps程度の回線）であっても、数秒から数十秒で大規模なウェブサーバーをダウンさせられる点にあります。

この攻撃は全く新しいバグを突くものではなく、既存の2つの手法を組み合わせることで成立しています。

HPACK圧縮増幅攻撃: ヘッダー圧縮機能の悪用
フロー制御の悪用: レスポンス送信を停止させ、リソースを保持し続ける（Slowloris型）

実際にどのような流れで攻撃が行われるのか、以下の図にまとめてみました。

sequenceDiagram
    participant Attacker as 攻撃者 (家庭用PC)
    participant Server as ウェブサーバー

    Note over Attacker, Server: 第1段階：HPACK動的テーブルの構築
    Attacker->>Server: ヘッダー情報を送信してテーブルに登録
    Server-->>Attacker: 承諾

    Note over Attacker, Server: 第2段階：リソースの占有
    Attacker->>Server: 1バイトのインデックス参照（巨大なデータに展開）
    Note right of Server: メモリを大量に割り当て

    Attacker->>Server: フロー制御ウィンドウを「0」に設定
    Note right of Server: 送信待ち状態でプロセスが停滞
    Note right of Server: 割り当てたメモリが解放されない

    loop 繰り返し
        Attacker->>Server: 短いパケットを大量に送信
    end

    Note over Server: 数秒〜数十秒でメモリ（RAM）枯渇

攻撃の核心：HPACKとフロー制御の「掛け算」

この攻撃が強力な理由は、サーバー側のリソースを効率よく「拘束」し続ける仕組みにあります。

HPACKによるメモリ増幅

HTTP/2では通信を効率化するために、共通のヘッダーを「動的テーブル」に保存し、2回目以降は短いインデックス（たとえば1バイト程度）で参照する「HPACK」という仕組みが使われています。攻撃者はこれを利用して、1バイトのデータを受け取ったサーバー側が、内部で数千バイトのメモリを割り当てるように仕向けます。たとえば、辞書の1文字を指すだけで、サーバー側では分厚い百科事典を開かされるようなイメージでしょうか。

フロー制御による「解放の阻止」

通常、メモリが大量に消費されても、処理が終われば解放されます。しかし、ここで攻撃者は「フロー制御」の機能を悪用します。サーバーに対して「今はデータを受け取れない（ウィンドウサイズ 0）」と通知することで、サーバーはレスポンスを送る直前で「待ち」の状態になります。これにより、展開された巨大なメモリデータが解放されずに残り続け、サーバーのメモリ（RAM）をあっという間に埋め尽くしてしまいます。

主要サーバーへの影響比較

研究者のテストによれば、デフォルト設定の主要なウェブサーバーはいずれもこの攻撃に対して脆弱であることが示されています。こちらの表は、32GB（または64GB）のRAMが枯渇するまでにかかった時間の目安です。

サーバーの種類	メモリ枯渇までの時間	消費メモリ量
Envoy 1.37.2	約10秒	32GB
Apache httpd 2.4.67	約18秒	32GB
nginx 1.29.7	約45秒	32GB
Microsoft IIS (Windows Server 2025)	約45秒	64GB

Envoyについてはわずか10秒ほどで32GBのメモリを使い果たしており、対策なしでは非常に危険な状態になることがわかります。

AIによる脆弱性発見の側面

今回、この攻撃手法の発見に「OpenAI Codex」が関わっている点も見逃せません。研究者は、AIを活用してプロトコルの複雑な仕様を分析する中で、この隠れた組み合わせを見つけ出したそうです。

AIがセキュリティリスクの発見に役立つ一方で、攻撃者側にとっても同様のツールになり得るという点は、今後のシステム設計において考慮すべき課題かもしれません。

まとめと対策

現状、この攻撃を防ぐためには、HTTP/2の動的テーブルサイズや、並列リクエスト数、アイドルタイムアウトの設定を適切に見直す必要があるかと思います。主要なサーバーソフトウェアでは既に対策やパッチの議論が進んでいるはずですので、管理しているサーバーのアップデート状況を確認してみるのが良いかもしれません。

「標準的な仕様」に従っているからといって安全とは限らない、という教訓を改めて感じさせる事例ではないでしょうか。

MicroArchitectures

H.Ueda

Programmer

ブログ