こんにちは、ネットアシスト運用チームのhaokiです。
今回は少し視点を変えた話をしたいと思います。
2026年6月3日、セキュリティ研究企業 Calif が「HTTP/2 Bomb」（CVE-2026-49975）を公開しました。注目すべきはその発見手法で、OpenAI の Codex を使って脆弱性を発見したと報告されています。
AIが脆弱性の発見を自動化し始めた今、CVEの公開ペースはこれまで以上に上がる可能性があります。パッチが出るまでの空白期間に何が起きているのか、運用側が自分で挙動を把握できる環境を持っておくことの重要性が増しています。
今回はその一例として CVE-2026-49975 を取り上げつつ、さくらのクラウドで検証用サンドボックスを手早く作る方法を紹介します。
CVE-2026-49975（HTTP/2 Bomb）とは
| 項目 | 内容 |
|---|---|
| CVE ID | CVE-2026-49975 |
| 通称 | HTTP/2 Bomb |
| 開示日 | 2026年6月3日 |
| 深刻度 | Critical（Remote DoS） |
| 影響対象 | Apache HTTPD / NGINX / Microsoft IIS / Envoy / Cloudflare Pingora |
| 攻撃要件 | 認証不要、単一のTCP接続 |
NGINX、Apache、IIS、Envoyといった主要WebサーバーのデフォルトのHTTP/2設定を狙ったリモートDoS攻撃です。家庭用の100Mbps回線1本から、数秒でサーバーのRAMを使い切らせることができ、影響を受けるサーバーはShodanの調査時点で880,000以上とのこと。
攻撃の仕組み
攻撃は2つの技術の組み合わせです。
① HPACK圧縮爆弾
HTTP/2はヘッダーを「HPACK」という形式で圧縮して送ります。攻撃者はHPACKのDynamic Tableの仕組みを悪用し、数十バイトの圧縮データをサーバー側で数十MBのヘッダーオブジェクトに展開させます。Envoyでは5,700:1の展開比が確認されています。
② Slowlorisスタイルのフロー制御ホールド
HTTP/2の流量制御を意図的に止めることで接続を「処理中」のまま維持し、展開したオブジェクトをメモリに留め置き続けます。
緩和策
- Apache：mod_http2 を 2.0.26 以降にアップデート（
dnf update httpd） - NGINX：1.29.8 以降にアップデート
- IIS / Envoy：2026年6月時点でパッチ未公開。HTTP/2の一時無効化か前段WAFで対応
- 共通：CDN利用中でもオリジンへの直接経路が残っていないか確認
パッチが追いつかない時代のサンドボックスの必要性
今回の CVE-2026-49975 は Apache と NGINX については比較的早くパッチが出ましたが、IIS・Envoy・Pingora は開示時点でパッチ未公開でした。
そしてこの脆弱性はAIを使って発見されています。今後こうしたケースが増えていくとすれば、「パッチが出るまで待つ」だけでは対応が後手に回るリスクが高まります。
運用側として現実的な対策は：
- 脆弱性が公開されたとき、自分の環境が影響を受けるかを素早く判断する
- 影響を受ける場合、パッチ待ちの間に何が起きているかを把握して暫定対処を取る
そのためには安全に攻撃の挙動を試せるサンドボックス環境を手早く作れることが重要です。
さくらのクラウドでサンドボックスを作る
設計の考え方
検証環境に求める条件はシンプルです。
- 攻撃コードが外部に出ない（誤爆しない）
- 素早く作れて、素早く捨てられる
- 本番に近い環境で試せる
さくらのクラウドのプライベートスイッチを使えば、インターネットに一切出ないL2セグメントをGUI操作だけで数分で作れます。
ただし閉域にしてしまうと dnf install でパッケージが取れないため、手順を2段階に分けます。
【Step 1】パブリックNICあり → セットアップを済ませる
【Step 2】コントロールパネルでパブリックNICを取り外す → 完全閉域に切り替えまた、閉域化後はSSHで接続できなくなります。さくらのクラウドのコンソール機能（コントロールパネルのブラウザコンソール）から操作することになります。
ネットワーク構成
[攻撃インスタンス] [ターゲットインスタンス]
AlmaLinux 9 AlmaLinux 9
2 vCPU / 4GB RAM 4 vCPU / 8GB RAM
192.168.100.10 192.168.100.20
↑ プライベートスイッチのみ（外部疎通なし）Step 1：サーバーの構築とセットアップ
まず通常通りパブリックNICつきでサーバーを2台（攻撃側・ターゲット側）作成します。この段階ではインターネットに繋がっているので、SSH経由で各種パッケージのインストールや設定を済ませておきます。
Step 2：プライベートスイッチの作成
セットアップが完了したら、コントロールパネルの「ネットワーク」→「スイッチ」からプライベートスイッチを作成します。
スイッチ名: sandbox-http2bomb
ルータ: 接続しない ← ここが重要Step 3：サーバーを停止してNICを差し替える
さくらのクラウドはNICの編集にサーバーの停止が必要です。両インスタンスをシャットダウンします。
[root@target ~]# shutdown -h now停止を確認したら、コントロールパネルで各インスタンスのNICを操作します。
① NIC一覧 → 「追加」→ プライベートスイッチ（sandbox-http2bomb）を選択して追加
② NIC一覧 → eth0（インターネット側）→ 削除両インスタンスとも同様に操作したらサーバーを起動します。
Step 4：コンソールからプライベートIPを割り当て
閉域化後はSSHで接続できません。以降の操作はコントロールパネルの「コンソール」タブからブラウザコンソールで行います。
コンソールからログインし、接続名を確認します。
[root@target ~]# nmcli connection show
NAME UUID TYPE DEVICE
System eth0 5fb06bd0-... ethernet eth0
lo e5c758de-... loopback loNICを付け替えた後も接続名は System eth0 のままでした。ip a でIPを確認し、プライベートセグメントのアドレスに書き換えます。
# ターゲット側
[root@target ~]# nmcli connection modify "System eth0" ipv4.method manual ipv4.addresses 192.168.100.20/24
[root@target ~]# nmcli connection up "System eth0"
# 攻撃側
[root@attacker ~]# nmcli connection modify "System eth0" ipv4.method manual ipv4.addresses 192.168.100.10/24
[root@attacker ~]# nmcli connection up "System eth0"疎通確認して閉域環境の完成です。
# プライベート経由は繋がる
[root@attacker ~]# ping -c 3 192.168.100.20
64 bytes from 192.168.100.20: icmp_seq=0 ttl=64 time=0.4 ms
# インターネットへは出られない
[root@attacker ~]# curl -s --max-time 5 https://example.com
curl: (28) Connection timed out after 5000 millisecondsまとめ
CVE-2026-49975 はAIを使って発見された脆弱性です。こうしたケースが今後増えていくとすれば、パッチを待つだけの受け身の対応では追いつかなくなる可能性があります。
さくらのクラウドのプライベートスイッチとNICの付け外し機能を使えば、外部に一切出ない検証環境を数分で作れます。気になるCVEが出たときにすぐ試せる環境を用意しておくことをお勧めします。
なお今回の構築手順でハマりやすいポイントをまとめると：
- NICの追加・削除はサーバーの停止が必要
- nmcli のコマンドはバックスラッシュ改行を使わず1行で実行する
- 閉域化後はSSH不可。コントロールパネルのコンソールから操作する
さくらのクラウドを使ったサーバーの監視・運用体制の整備についてご相談がある方は、ぜひネットアシストにご連絡ください。
それではまた！
