22
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

CVE-2026-49975「HTTP/2 Bomb」をわかりやすく解説——AIが人間より先に気づいた脆弱性

22
Posted at

TL;DR

  • CVE-2026-49975(通称 HTTP/2 Bomb)は、HTTP/2 の仕様上の組み合わせを悪用したリモート DoS 脆弱性
  • OpenAI Codex が nginx・Apache・IIS・Envoy・Cloudflare Pingora の 5 つの主要 Webサーバーに共通する問題を人間より先に発見した
  • 家庭用の 100 Mbps 回線 1 本で 32GB の RAM を 20 秒以内に枯渇させられる
  • 現時点でパッチ未適用の環境は HTTP/2 を無効化し WAF で防御するのが最優先

CVE-2026-49975 とは何か

2026 年 6 月 3 日、セキュリティ企業 Calif が CVE-2026-49975 を公開しました。正式名称は 「HTTP/2 Bomb」 で、認証不要でリモートから Webサーバーをクラッシュさせる重大な DoS(サービス拒否)脆弱性です。

攻撃の特徴は、既存の 2 つの技術を組み合わせた点にあります。

技術 説明
HPACK 圧縮テーブル増幅 HTTP/2 のヘッダー圧縮テーブルを悪用し、小さなリクエストをサーバー側で大量のメモリ割り当てに変換する
Slowloris スタイルのフロー制御ホールド HTTP/2 のウィンドウサイズを 0 に保ち、割り当てたメモリを解放させない

攻撃の流れ

攻撃者                           Webサーバー
  │                                  │
  │── 大きなヘッダーを1回送信 ────────→│ HPACKテーブルに登録
  │                                  │
  │── 1バイトの参照を数千回送信 ──────→│ ×参照ごとに元のヘッダーをメモリ展開
  │                                  │   (小→大 の爆発的増幅)
  │                                  │
  │── フロー制御ウィンドウ = 0 に設定 →│ ×メモリを解放できない
  │                                  │
  │             〜20秒後〜            │
  │                                  │ OOM でクラッシュ💥

これにより、家庭用インターネット接続 1 本で 32GB の RAM を約 20 秒で使い切ることが確認されています。


影響を受けるシステム

Shodan のスキャンでは、88 万件以上のパブリックサーバーが脆弱な状態で公開されていることが確認されました。

プロダクト パッチ状況(2026年6月3日時点)
nginx ✅ パッチ済み(4月にヘッダーカウント指令を追加)
Apache httpd ✅ mod_http2 v2.0.41 で修正(5月27日リリース)
Microsoft IIS ❌ 未パッチ
Envoy proxy ❌ 未パッチ
Cloudflare Pingora ❌ 未パッチ

CVSS スコアは 7.5〜Critical と評価されており、エクスプロイトの PoC(概念実証コード)もすでに公開済みです。


「AI が人間より先に気づいた」という衝撃

Codex が発見するまで

この脆弱性の最大のインパクトは、攻撃手法そのものよりも発見の経緯にあります。

Calif のセキュリティ研究者が OpenAI Codex を使って複数の Webサーバーのソースコードを解析させたところ、Codex は次のことをやってのけました。

「HPACK 圧縮の増幅効果」と「HTTP/2 フロー制御によるメモリホールド」という10 年以上前から個別に知られていた 2 つのテクニックが、組み合わさると破壊的な新しい攻撃チェーンになると認識した。

研究者たちによれば、人間のセキュリティ研究者は誰もこれらのサーバーに対してこの組み合わせを試みたことがなかったとのことです。Codex はソースコードを横断的に読み、5 つの主要サーバー実装に共通する構造的欠陥を数時間以内に特定しました。

なぜ AI はこれが得意なのか

人間の研究者がこの脆弱性を見逃した理由の一つは、知識のサイロ化です。nginx を専門とする研究者は Envoy のコードをあまり読まず、Apache の専門家は Cloudflare Pingora のコードを見ない傾向があります。

一方で AI には「分野をまたぐ読破」に障壁がありません。

比較軸 人間の研究者 AI(Codex など)
読めるコード量 1日あたり数千〜数万行 数百万行を一度に処理可能
知識のサイロ 専門分野に集中しがち 複数の実装を横断的に比較
既知技術の組み合わせ発見 直感・経験が必要 パターンマッチングが得意
疲労・見落とし ある ない
新しい攻撃コンテキストへの応用 時間がかかる 高速

AI による脆弱性発見は増加している

CVE-2026-49975 は孤立した事例ではありません。2025〜2026 年にかけて、AI を用いた脆弱性発見の事例が急増しています。

  • 2026 年 1 月: AISLE Research の自律型 AI が OpenSSL に 12 件の脆弱性を一括発見。中には 1998 年から 27 年間潜伏していたバグも含まれていた
  • 2026 年 3 月: GitHub Security Lab が AI エージェントで 80 件以上の脆弱性を発見・報告
  • 2026 年 4 月: Anthropic が Project Glasswing / Claude Mythos を発表。主要 OS やブラウザから数千の ゼロデイ脆弱性を特定したと発表
  • CVE 開示件数: 2025 年は 4 万 8,000 件超(2023 年比 +38%)。Chrome +563%、Apache +170% という急増の背景に AI 支援が指摘されている

対策:今すぐできること

短期対策(即時対応)

  1. パッチを適用する

    • nginx: 最新版にアップデート
    • Apache httpd: mod_http2 v2.0.41 以降にアップデート
    • IIS / Envoy / Pingora: パッチリリースを待ちながら下記の緩和策を適用
  2. パッチ適用まで HTTP/2 を無効化する

    # nginx の場合
    server {
        listen 443 ssl;
        # http2 を削除してダウングレード
        # listen 443 ssl http2;  ← コメントアウト
    }
    
    # Apache httpd の場合
    # httpd.conf または VirtualHost 内
    Protocols http/1.1
    # H2 / h2c を列挙から除外
    
  3. HTTP/2 ヘッダー数の上限を設定する

    # nginx
    http2_max_field_size 8k;
    http2_max_header_size 16k;
    large_client_header_buffers 4 8k;
    
  4. 接続タイムアウトを短く設定する(Slowloris 対策)

    keepalive_timeout 30s;
    client_header_timeout 15s;
    

中期対策(1〜2 週間以内)

  1. WAF(Web Application Firewall)を導入・設定する

    • Imperva、Cloudflare WAF などのクラウド WAF はすでに CVE-2026-49975 向けシグネチャを提供
    • WAF でエッジレベルで HPACK の異常パターンを遮断できる
  2. リソース制限を設定する

    # systemd でメモリ制限を設定(Webサーバーの爆発的メモリ消費を抑制)
    [Service]
    MemoryMax=4G
    MemoryHigh=3G
    
  3. ログ・モニタリングを強化する

    • 異常なヘッダーパターンや急激なメモリ使用量の上昇を検知するアラートを設定

確認コマンド

# nginx のバージョン確認
nginx -v

# Apache httpd の mod_http2 バージョン確認
httpd -M | grep http2
apachectl -M | grep http2

# HTTP/2 の有効状態を確認(外部から)
curl -I --http2 https://your-server.example.com

AIによる脆弱性発見——私たちにできることは何か

問題の構造

CVE-2026-49975 は「AI がセキュリティ研究を変えつつある」という事実を示しました。しかしここには両刃の剣としての側面があります。

防御側の AI                          攻撃側の AI
  ↓                                    ↓
脆弱性を発見してパッチを促す           脆弱性を悪用してエクスプロイトを生成する

今のところ CVE-2026-49975 は防御的な研究から生まれましたが、同じ手法を悪意ある攻撃者が使えば、発見から悪用までの時間は劇的に短縮されます。

開発者・エンジニアとして今できること

1. AI 支援によるセキュリティレビューを日常に取り込む

# 例:GitHub Copilot Autofix を CI に組み込む
# .github/workflows/security.yml
jobs:
  security:
    steps:
      - uses: actions/checkout@v4
      - name: Run CodeQL Analysis
        uses: github/codeql-action/analyze@v3

SAST(静的解析)ツールに AI を組み合わせることで、コードレビュー段階でのバグ発見率を高められます。

2. 既知の攻撃パターンの「組み合わせ」を意識する

CVE-2026-49975 が教えてくれたのは、「個別には無害に見えても、組み合わせると危険」という設計上の盲点です。

  • プロトコル実装のセキュリティレビューでは、隣接するサブシステムとの相互作用を意識する
  • 特に フロー制御・バッファ管理・タイムアウト が絡む部分は複数の視点でレビューする

3. パッチサイクルを短縮する

AI が脆弱性を発見するスピードが上がると、ゼロデイから悪用までの窓口期間が短くなる可能性があります。

フェーズ 以前 AI 時代
発見 数週間〜数ヶ月 数時間〜数日
PoC 作成 数日〜数週間 数時間
悪用開始 公開後数週間 公開後数日
→必要なパッチ適用速度 週単位 日〜時間単位

CI/CD パイプラインに自動パッチ適用・テスト・デプロイのフローを整備しておくことが重要です。

4. 脆弱性開示(CVD)プログラムへの参加・支援

AI ツールを使ったセキュリティ研究を「悪いもの」として規制するのではなく、責任ある開示(Responsible Disclosure) の文化と制度に取り込む方向が重要です。バグバウンティプログラムを設置・参加することで、AI 発見の脆弱性が悪用前に修正される確率が上がります。

5. インフラを「リソース制限付きで設計する」習慣をつける

メモリ枯渇系の攻撃に対して最も強力な根本的防御は、最初からリソース上限を設計に組み込むことです。

# Kubernetes でリソース制限を設定する例
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"   # これを超えるとコンテナがOOMKillされ、他へ影響しない
    cpu: "500m"

まとめ

CVE-2026-49975「HTTP/2 Bomb」は、AI が実際の重大脆弱性を人間より先に発見したことを示した象徴的な事例です。

Codex は、10 年以上個別に知られていた 2 つの技術(HPACK 増幅 + Slowloris ホールド)を横断的に読み解き、5 つの主要 Webサーバーに共通する破壊的な組み合わせを見つけました。それは 88 万台超のサーバーに影響し、家庭用回線 1 本で 32GB の RAM を 20 秒で枯渇させます。

AI による脆弱性発見は今後も加速します。私たちエンジニアにできることは次の 3 つです。

  1. 今すぐパッチを当てる(または HTTP/2 を無効化して WAF で守る)
  2. AI 支援のセキュリティレビューを CI に組み込む
  3. パッチサイクルとインフラ設計を「AI 時代のスピード」に合わせる

脅威の発見がますます速くなる時代に、対応も同じ速さで動けるチーム・インフラを整えていきましょう。


参考リンク


この記事はZennでも公開しています。

22
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
22
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?