Tech BlogAWSツール & 技術ブログ
メニュー

カテゴリ

AWS & AI ツール

タグ

Claude Code13AI13AWS11セキュリティ8効率化5開発ツール5S34CloudFront4Claude4Next.js3プラグイン3CVE2すべて見る →

Apache HTTP Server の RCE 脆弱性 CVE-2026-23918 まとめ：AWS EC2 で Apache を使っている場合の確認・対処手順

セキュリティApacheHTTP/2CVEAWSEC2トラブルシューティング

はじめに

2026年5月、Apache HTTP Server に複数の脆弱性が同時公表されました。中でも CVE-2026-23918 は HTTP/2 のダブルフリーから RCE（リモートコード実行）に至る、CVSS 8.8 の High 評価で、未認証のリモート攻撃者が HTTP/2 リクエストを送るだけで成立しうる緊急性の高いものです。

参考記事: Apache HTTP Server RCE - Cyber Security News

このブログ自体は S3 + CloudFront 構成なので Apache は1台も使っていませんが、業務側ではまだ EC2 上で Apache を運用しているケースも多く、過去に Apache 環境のセキュリティパッチ対応をやってきた経験から、AWS 環境で「自分のところは大丈夫か」を判断するためのチェックポイントと、実際のアップグレード手順をまとめます。

少し前の Linux カーネル脆弱性「Copy Fail」のときと同じように、Amazon Linux 系では ALAS の状況を確認するのが起点 になります（ALAS = Amazon Linux Security Advisories。参考: Linuxカーネル脆弱性 Copy Fail のまとめ）。

脆弱性概要

今回の Apache HTTP Server まわりでは、5件の CVE が同時公表されています。

CVE 種別 深刻度 影響バージョン
CVE-2026-23918 HTTP/2 ダブルフリー → RCE High（CVSS 8.8） 2.4.66 のみ
CVE-2026-24072 mod_rewrite 権限昇格 Medium 2.4.66 以前
CVE-2026-28780 mod_proxy_ajp バッファオーバーフロー Low 2.4.66 以前
CVE-2026-29168 mod_md OCSP リソース枯渇 Low 2.4.30 〜 2.4.66
CVE-2026-29169 mod_dav_lock NULL ポインタ Low 2.4.66 以前

修正バージョンは Apache HTTP Server 2.4.67（2026-05-04 リリース）。

注意したいのは、影響バージョンが CVE ごとに違うことです。RCE である CVE-2026-23918 は 2.4.66 にだけ存在する リグレッション系のバグですが、他の4件は古いバージョンも対象です。「うちはまだ古いから関係ない」は通用しません。

CVE-2026-23918 の仕組み

mod_http2 が HTTP/2 ストリーム処理中に「早期ストリームリセット」（RST_STREAM フレーム）を受けたとき、同じヒープ領域を2回 free してしまうバグです。

  • ダブルフリー → ヒープのフリーリスト汚染 → 同一プロセス内で任意コード実行
  • ネットワーク経由・未認証で成立
  • HTTP/2 を有効にしていれば成立条件が成立

過去の Apache の RCE と違って、設定ミスではなく素のデフォルト構成でも踏みうる のが厄介です。

AWS EC2 への影響範囲

「EC2 で Apache を使っている＝即対象」ではありません。CVE-2026-23918（RCE）の対象になるのは以下の3条件をすべて満たす場合です。

  1. Apache HTTP Server のバージョンが 2.4.66
  2. HTTP/2 が有効（mod_http2 がロードされ、Protocols ディレクティブに h2 または h2c が含まれる）
  3. HTTP/2 を受ける ポートが信頼できないネットワークから到達可能

ALB を前段に置いて HTTP/2 終端を ALB で受けている構成（Apache 直前は HTTP/1.1）であれば RCE のリスクは下がります。ただし他4件の CVE は 2.4.66 未満も対象なので、結局はアップグレードが必要というのが結論です。

ECS（EC2 起動タイプ）や EKS のワーカーノード上のコンテナで Apache を使っているケースも当然対象です。AMI 単位だけでなく、コンテナイメージのベース更新も忘れないこと。

「2.4.66 未満なら安全」ではない

繰り返しになりますが、RCE である CVE-2026-23918 は 2.4.66 のみです。古いバージョンを使っていれば RCE 自体は踏まないものの、

  • 残り4件の CVE は古いバージョンも対象
  • さらに過去の累積 CVE（CVE-2021-41773 / CVE-2021-42013、CVE-2023-25690、CVE-2024-38475 など）が古いバージョンに残っている可能性

これらを踏まえると、バージョンを問わず 2.4.67 以降に上げる のが唯一の正解です。「触ってないから安全」は誤りで、放置されているほど蓄積 CVE は増えます。

確認手順

EC2 にログインして、まずバージョンと有効モジュールを確認します。

# バージョン確認
httpd -v          # Amazon Linux 系・RHEL 系
apache2 -v        # Debian / Ubuntu 系

# 有効モジュール確認（影響を受ける可能性のあるモジュールに絞って grep）
httpd -M 2>/dev/null | grep -E 'rewrite|proxy_ajp|md_module|dav_lock|http2'

# Protocols 設定（HTTP/2 が有効か確認）
grep -RIn "Protocols" /etc/httpd/ /etc/apache2/ 2>/dev/null

# パッケージ更新の可否
dnf info httpd            # Amazon Linux 2023
yum info httpd            # Amazon Linux 2
apt-cache policy apache2  # Ubuntu / Debian

複数台ある場合、AWS Systems Manager の Run Command で同じシェルを一斉に投げるのが効率的です。タグでターゲット EC2 を絞り込み、AWS-RunShellScript で httpd -v && httpd -M | grep http2 を流すだけで一覧化できます。

対処方法（推奨順）

A. 恒久対応：2.4.67 以降へアップグレード

OS パッケージで提供されている場合は、それで上げるのが一番素直です。

# Amazon Linux 2023
sudo dnf update httpd && sudo systemctl restart httpd

# Amazon Linux 2
sudo yum update httpd && sudo systemctl restart httpd

# Ubuntu / Debian
sudo apt update && sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

注意点として、ディストロのパッケージは独自リビジョン（例: 2.4.62-1.amzn2.0.4）で管理されているため、表面のバージョン番号が 2.4.67 でなくても、changelog に「Backport CVE-2026-23918 fix」のような記載があればパッチ適用済みとみなせます。dnf changelog httpd で確認可能です。

ALAS が「Pending Fix」の状態であれば、修正パッケージが提供されるまで暫定対応を入れて待つことになります。

B. 暫定対応：HTTP/2 を無効化（CVE-2026-23918 のみ向け）

# httpd.conf or conf.modules.d/*.conf
# LoadModule http2_module modules/mod_http2.so をコメントアウト
# または
Protocols http/1.1

sudo apachectl configtest
sudo systemctl restart httpd

性能影響あり（HTTP/2 のマルチプレキシングが効かなくなる）なので、アップグレードまでの応急処置と割り切ること。残り4件の CVE には効きません。

C. 多層防御（並行実施）

  • AWS WAF や ALB を前段に置き、HTTP/2 終端を ALB に寄せる（Apache 直前は HTTP/1.1）
  • セキュリティグループで Apache の直公開ポートを最小化
  • 不要モジュール（mod_dav_lock / mod_proxy_ajp 等）を停止
  • AWS Inspector / SSM Patch Manager で CVE 検出と自動パッチ適用を回す

WAF で HTTP/2 の RST_STREAM フラッディングを完全にフィルタするのは難しいので、WAF だけで対応は完結しません。あくまで「侵入の入口を狭める」役割と理解すること。

業務での運用感

過去に EC2 上で Apache を運用していたときの感覚で言うと、Apache のメジャーアップデートが原因で動かなくなる確率は低めです。一方で mod_security や独自の mod_rewrite ルール、SSL 設定（特に SSLProtocol / SSLCipherSuite の警告）まわりで微妙な挙動差が出ることはありました。

CI 環境や検証 AMI で同じバージョンの httpd に上げて、apachectl configtest と主要エンドポイントのスモークテストを回してから本番に当てる。当たり前のことですが、これを省くとリブート後にサービスが落ちて初めて気づく、ということになりがちです。

加えて、Auto Scaling グループの起動テンプレートで使っている AMI も忘れず再ビルドすること。古い AMI のままだとスケールアウト時に脆弱なインスタンスが復活します。これは Linux カーネル脆弱性の対応と同じ考え方ですね。

チェックリスト

  • 全 EC2（Auto Scaling 配下含む）でバージョン確認
  • HTTP/2 設定の有無を確認
  • 2.4.66 で HTTP/2 有効なホストを 最優先で 洗い出し
  • 2.4.67 以降へ更新（OS パッケージまたはベンダー修正版）
  • AMI（ゴールデンイメージ）を再ビルドして固定化
  • AWS Inspector で CVE-2026-23918 等が消えたことを確認
  • ECS / EKS で使っているコンテナイメージのベース更新も実施

注意

インフラ設定の変更は本番影響があるため、本番適用前にインフラ担当のレビューを必ず通すこと。特に HTTP/2 を一時的に切る暫定対応は、API クライアントの実装によってはエラーになるケースもあるため、フロント・モバイル側との調整が必要です。

このブログの方針として、本番に直結するコード変更（認証・認可、外部 API 連携、インフラ設定変更）は人間のレビューを必ず挟むことにしています。CVE 対応も同じ枠組みで動くべきで、AI 支援であってもパッチ適用そのものは人間が責任を持って当てる、という線引きを推奨します。

まとめ

  • CVE-2026-23918 は Apache 2.4.66 + HTTP/2 有効の組み合わせで RCE に至る High な脆弱性
  • 同時公表の他4件は 2.4.66 未満も対象。バージョンを問わず 2.4.67 以降にアップグレード が正解
  • AWS では ALAS と SSM の Patch Manager / Inspector を起点に状況把握する
  • HTTP/2 無効化は応急処置で、恒久対応はアップグレード
  • AMI / コンテナイメージの更新も忘れないこと

詳細は 元記事 と Apache 公式の Security Advisories を併読することをおすすめします。

関連記事

← 記事一覧に戻る