Apache HTTP Server 2.4.67緊急リリース｜HTTP/2 Double FreeでRCE

この記事ではセキュリティに特化して解説します。AIセキュリティ全般は サプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

何が起きたか — 結論ファースト

世界で最も使われているWebサーバーのひとつ Apache HTTP Server に、HTTP/2プロトコル実装の不備に起因する深刻な脆弱性 CVE-2026-23918 が公表された。HTTP/2の「early stream reset」シーケンスを悪用すると同じメモリ領域に対する二重解放（Double Free）が発生し、ヒープメモリ破壊を経由して認証不要・ユーザー操作不要のリモートコード実行（RCE）に至る恐れがある。攻撃複雑度（AC）は低く、PoC公開後の悪用敷居も低くなる見込みだ。

修正版 Apache HTTP Server 2.4.67 は2026年5月4日にリリースされ、修正コミットは2025年12月11日付の r1930444。同じリリースでは関連する4件のCVEもまとめて修正されており、HTTP/2の有無にかかわらず、すべての2.4.66以前ユーザーが対象だ。

あなたは影響を受けるか — 30秒判定

CVE-2026-23918の根本原因 — HTTP/2 Double Free

HTTP/2の「early stream reset」とは

HTTP/2は単一TCP接続上で複数の論理ストリームを多重化する。クライアントは RST_STREAM フレームを送ると任意のタイミングでストリームを中断でき、CDN／ブラウザのキャンセル動作に使われる正規仕様だ。

問題はストリームのライフサイクル管理と、リクエストボディ／レスポンス送信用の内部バッファ管理の整合性が崩れた瞬間に起きる。具体的には次の順序が引き金になる：

1. クライアントが新しいストリームを開く（HEADERS フレーム）
2. サーバーがリクエストの一部を受け取り、内部リクエスト構造体とバッファを確保
3. クライアントがほぼ同時に RST_STREAM を送り「early stream reset」を発火
4. サーバー側で通常のリクエスト終了処理とストリームリセット時のクリーンアップが並行して走る
5. 同一バッファが2系統のクリーンアップから free() される → Double Free

Double FreeがRCEに変わる仕組み

Double Free単体は「クラッシュ」で済むことも多いが、glibc等のヒープアロケータでは同一チャンクが2度 free リストに入り、次の同サイズ allocation で攻撃者制御のメタデータが書き戻る条件を作れる。これに HTTP/2 のヘッダ圧縮（HPACK）バッファや一時アロケーションを組み合わせると、関数ポインタや vtable に到達し、最終的に任意コード実行（RCE）に発展しうる。

攻撃前提 — 何が必要で、何が不要か

「外部公開のApache + HTTP/2 + 2.4.66以前」が揃ったら、追加要件なしで攻撃が成立すると理解しておきたい。インターネット直結のリバースプロキシや静的配信サーバーは特に優先度が高い。

同時修正された4つの脆弱性

2.4.67のリリースノートでは、本丸の CVE-2026-23918 のほかに4件のCVEがまとめて修正されている。「うちはHTTP/2を切ってるから無関係」と判断するのは危険で、別の経路でも刺さる可能性がある。

影響範囲 — 「Millions at Risk」の中身

Apache HTTP Serverは1995年初版以降、Webサーバーシェアの上位を維持してきた。Cloud／VPS／オンプレに跨り、特にリバースプロキシ用途としての運用も多い。今回のCVEを「数百万台規模」と海外メディアが評するのは、次のような累積要因による。

• HTTP/2の標準化 ：パフォーマンス向上目的で Protocols h2 http/1.1 を有効化する構成が増加
• TLS終端役の集中 ：CDN前段／L7ロードバランサ前段としてのApacheに集中
• OSパッケージ更新の遅延 ：ディストロのバックポート版に依存し、ベンダ提供のセキュリティパッチが届くまでタイムラグ
• 長期稼働マシン ：再起動・無停止運用を優先し、minor更新を見送るケース

特に 外部公開セグメント／DMZ／APIゲートウェイ前段 のApacheは、CVE-2026-23918のRCEに直撃される可能性が高い。マルチテナントSaaSのフロント側にいるなら、テナント間境界の崩壊にもつながりうる。

即時対応 — バージョン確認とアップグレード

バージョン確認コマンド

まずは自環境が2.4.66以前かを把握する。

# 直接確認（Apacheバイナリから）
httpd -v
# Server version: Apache/2.4.66 (Unix)
# Server built:   Mar  5 2026 12:34:56

# Debian/Ubuntu系
apache2 -v
dpkg -l | grep -E "apache2|libapache2"

# RHEL/CentOS/Rocky/AlmaLinux
rpm -q httpd mod_http2

# ロード中のモジュール一覧（HTTP/2有効か確認）
httpd -M 2>/dev/null | grep -Ei "http2|proxy_ajp|auth_digest|dav_lock|rewrite"

httpd -M の出力に http2_module が含まれていれば、CVE-2026-23918の悪用条件を満たす可能性がある。apache2ctl -M でも同等の確認が可能だ。

パッケージ更新

ディストロのセキュリティリポジトリから配信されるバックポート版を当てるのが本筋。

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade apache2 libapache2-mod-http2

# RHEL / Rocky / AlmaLinux 8/9
sudo dnf clean all
sudo dnf upgrade --refresh httpd mod_http2

# Amazon Linux 2023
sudo dnf upgrade httpd mod_http2

# 最後に再起動
sudo systemctl restart apache2   # Debian系
sudo systemctl restart httpd     # RHEL系

ソースから入れている環境向け

ディストロ管理ではなく ./configure && make で運用している環境は、公式 tarball から直接更新する。

# 公式ミラーから2.4.67を取得
curl -fsSL -O https://dlcdn.apache.org/httpd/httpd-2.4.67.tar.gz
curl -fsSL -O https://dlcdn.apache.org/httpd/httpd-2.4.67.tar.gz.sha256
sha256sum -c httpd-2.4.67.tar.gz.sha256

# ビルド
tar xzf httpd-2.4.67.tar.gz
cd httpd-2.4.67
./configure --prefix=/usr/local/apache2 --enable-http2 --enable-ssl
make -j"$(nproc)"
sudo make install

# graceful restart（接続を切らない）
sudo /usr/local/apache2/bin/apachectl -k graceful

Docker／コンテナ環境

公式イメージの再取得とロールアウトでパッチを反映する。

# 最新タグを取得（2.4.67がpublishされていることを確認）
docker pull httpd:2.4.67

# イメージのバージョン確認
docker run --rm httpd:2.4.67 httpd -v

# Compose環境
docker compose pull web
docker compose up -d web

暫定対策 — すぐにアップグレードできない場合

緊急メンテナンス窓の確保が困難な場合の最小限の延命策を整理する。

A. HTTP/2を一時無効化（CVE-2026-23918の悪用条件を断つ）

Protocols ディレクティブから h2 を外す。

# /etc/apache2/apache2.conf もしくは /etc/httpd/conf/httpd.conf

# 旧設定（HTTP/2有効）
# Protocols h2 http/1.1

# 暫定: HTTP/1.1のみに退避
Protocols http/1.1

# モジュール自体をロードしない場合
# LoadModule http2_module modules/mod_http2.so  ← コメントアウト

設定後は次の手順で反映する。

sudo apachectl configtest
sudo systemctl reload apache2  # または httpd

クライアント側にHTTP/1.1へのフォールバックが発生するため、TLS ALPNネゴシエーションが正常に切替わるか curl で確認する。

# HTTP/2 を要求しても 1.1 で返ってくれば暫定対策成功
curl -sI --http2 -o /dev/null -w "ALPN: %{http_version}\n" https://example.com
# 期待: ALPN: 1.1

B. WAF・IDSでHTTP/2の異常パターンを検知

HTTP/2 の RST_STREAM 連発や、極端に短いストリーム生存時間など、early stream reset を伴う異常パターンをルール化する。CDN／L7ロードバランサ側で先に弾けるとなお良い。

C. mod_proxy_ajp の使用を見直す

Tomcat等への AJP 連携を残している場合、CVE-2026-28780 のヒープオーバーフローが別経路として残る。AJPは原則として外部公開せず、上流サーバを攻撃者が制御できないネットワーク境界に閉じ込める。

# AJP の Listen をループバック限定に
Listen 127.0.0.1:8009

# プロキシ先のホワイトリスト化
<Proxy "ajp://localhost:8009/">
    Require ip 127.0.0.1
</Proxy>

D. mod_auth_digest を Basic + TLS に置換

Digest認証のタイミング攻撃（CVE-2026-33006）が懸念される環境では、TLS終端＋Basic認証、もしくはOIDC等の外部認証へ移行する。Digest固有の利点（チャレンジレスポンスでのパスワード非送出）は、現代の運用ではTLSで概ね代替できる。

検出 — 攻撃された痕跡を探す

PoC公開後に実害が出た場合に備えて、初動で確認すべきログとシグナルを整理する。

# Apacheエラーログで mod_http2 の異常終了がないか
sudo grep -E "mod_http2|h2_session|child pid .* exit signal" \
  /var/log/apache2/error.log /var/log/httpd/error_log 2>/dev/null

# segfault / SIGSEGV / coredumpが急増していないか
sudo journalctl -u apache2 --since "7 days ago" | grep -Ei "segfault|sigsegv|core"

# 突発的な子プロセス再起動の頻度
sudo journalctl -u apache2 --since "24 hours ago" \
  | grep -Eo "child pid [0-9]+ exit" | wc -l

子プロセスが普段の桁を超えて再起動している場合、Double Freeに起因するクラッシュ（あるいは試行）の兆候かもしれない。/var/lib/systemd/coredump/ 配下のコアダンプも併せて確認する。

# coredump の有無
sudo ls -la /var/lib/systemd/coredump/ 2>/dev/null
coredumpctl list --since "7 days ago" 2>/dev/null

対応の優先順位 — チェックリスト

優先度: P0（最高緊急度） — 外部公開のApacheでHTTP/2有効環境は、24〜48時間以内のアップグレードを目標とする。内部閉域でも他4件のCVEがあるため、通常パッチサイクルでの統合適用を急ぐ。

• httpd -v / apache2 -v でバージョン洗い出し
• httpd -M で http2_module の有無確認
• mod_proxy_ajp、mod_rewrite、mod_auth_digest、mod_dav_lockの利用棚卸し
• ステージングで2.4.67の起動確認・回帰テスト
• 本番への段階展開（ローリング／カナリア）
• WAF／L7LBでHTTP/2異常パターンのアラート閾値見直し
• エラーログ・コアダンプ・systemd journal の過去7日分点検
• 暫定対応として HTTP/2 無効化を選んだ場合は復旧計画を別途管理
• 関連するCDN／リバースプロキシ前段の構成監査
• Renovate・Dependabot等のサプライチェーン防御 でランタイム以外の依存も並行点検

過去のApache HTTP/2脆弱性との比較

HTTP/2は「並行性とプロトコル状態管理が複雑」という構造的な脆弱性温床を持つ。直近年で語られた代表例と並べると、CVE-2026-23918の位置付けが見える。

「Rapid Reset」がDoSにとどまったのに対し、CVE-2026-23918はRCEまで伸びるのが今回の重さ。HTTP/2を有効化する判断は、性能メリットだけでなく実装側のメモリ安全性まで含めて評価する必要が一段強まったと言える。

開発者・運用者への教訓

1. プロトコル多重化はメモリ安全性の難所

HTTP/2に限らず、QUIC（HTTP/3）やgRPCなど、ストリーム多重化を伴うプロトコルはライフサイクル管理の不整合がメモリ破壊に直結する。Cで書かれたコア実装は特に、ストリームごとのバッファ所有権を明確化するレビュー観点が必要だ。

2. early-cancel パスは見落とされやすい

「正常系の途中キャンセル」は実装テストで網羅しにくく、ファジング（特にステートフルfuzz）でしか踏めない経路がある。Apache自身も内部的にCIにファジングを取り入れているが、今回の経路はリリースまで残った。プロトコルパーサのファジングは「キャンセル」「再送」「期限切れ」の3点を必ず織り込む。

3. パッチサイクルはモジュール構成の棚卸しと連動させる

ロードしているモジュール一覧が分かれば、毎回のCVE出現時に「該当／非該当」を素早く分類できる。Ansible／Terraform等のIaCで httpd -M 結果をエビデンス化しておくと、緊急時の判断が早い。

# IaC化用のスナップショット例（CIで定期実行）
httpd -M 2>/dev/null | sort > /var/log/httpd/loaded_modules.txt
sha256sum /var/log/httpd/loaded_modules.txt

4. 公開面の最小化が常に最後の砦

HTTP/2エンドポイントを「本当に必要なホスト」だけに限定する、AJPやWebDAVを外部公開しない、Digest認証ではなくTLS+OIDCに寄せる──こうした「攻撃面の縮減」は単発のCVEに依存しない普遍的な耐性を生む。今回の5件まとめてのCVEは、そのことを改めて強調するイベントだ。

関連トピック

本件は単独のCVEというより、「Webサーバ／プロキシ／プロトコル実装」のセキュリティ運用全体に波及する。同様の構造的問題は他のミドルウェアでも繰り返されており、合わせて読むと運用観点が補強される。

• Docker脆弱性CVE-2026-34040｜AuthZバイパスでホスト乗っ取り — 認可レイヤをバイパスするタイプの構造類似
• Composer CVE-2026-40261｜Perforce連携RCE — サードパーティプロトコルの不備

参照ソース

• Apache HTTP Server 2.4 vulnerabilities（公式アドバイザリ）
• NVD - CVE-2026-23918
• oss-security: Apache HTTP Server 2.4.67 release notes
• CybersecurityNews - Apache HTTP Server RCE
• apache/httpd GitHub リポジトリ

本記事について 本記事は最新セキュリティ脅威に基づく速報です。CVSSスコア・攻撃ベクター・修正版情報は公式アドバイザリの更新に追随します。組織内のセキュリティチーム・SRE／インフラチームに本情報を共有し、緊急対応を進めることを強く推奨します。

この記事はAI業界の最新動向を速報でお届けする「AI Heartland ニュース」です。