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

カテゴリ

AWS & AI ツール

タグ

AI24Claude Code23AWS12セキュリティ11Claude9効率化8開発ツール6プラグイン5S35CloudFront5Next.js4Opus 4.83すべて見る →

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

このブログ自体は静的サイトで（2026年5月に S3 + CloudFront から Cloudflare Pages へ移行済み）Apache は1台も使っていません。一方で業務では EC2 上の Apache を運用しており、今回の CVE-2026-23918 も実際に対応を入れました。その実体験をもとに、AWS 環境で「自分のところは大丈夫か」を判断するためのチェックポイントと、実際のアップグレード手順をまとめます。

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

この記事で扱う範囲

  • CVE-2026-23918 を含む今回の脆弱性群の技術的背景（なぜ HTTP/2 のデフォルト構成で踏みうるのか）
  • AWS 環境での影響範囲の判断方法とバージョン確認手順
  • 対処の優先順位（恒久対応・暫定対応・多層防御の切り分け）

想定読者

EC2（あるいは ECS / EKS のコンテナ）で Apache HTTP Server を運用している開発者・インフラ担当者を想定しています。脆弱性パターンの学習素材としても読めるよう、「デフォルト安全だと思っていた設定が実は危険」という観点を意識して整理しました。

脆弱性概要

今回の 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 だけで対応は完結しません。あくまで「侵入の入口を狭める」役割と理解すること。

AWS での対応フロー全体像

ここまでの確認・対処を、AWS のマネージドサービスを使った一連の流れとして整理すると、おおむね次のようになります。個々の要素はこの記事で触れてきたものを並べ直しただけですが、順序を意識すると対応の抜け漏れが減ります。

  1. ALAS で状況把握 — Amazon Linux 系なら、まず Amazon Linux Security Advisories で対象 CVE の修正パッケージが提供済みか「Pending Fix」かを確認する（起点）
  2. SSM Run Command で一斉確認 — タグでターゲット EC2 を絞り、AWS-RunShellScript でバージョンと有効モジュールを一覧化する
  3. 修正版の適用 — OS パッケージ（dnf / yum / apt）で 2.4.67 相当へ更新。提供前なら HTTP/2 無効化などの暫定対応で時間を稼ぐ
  4. Inspector で検出確認 — AWS Inspector で対象 CVE が検出されなくなったことを確認する
  5. AMI / コンテナイメージの再ビルド — Auto Scaling の起動テンプレートで使うゴールデン AMI、ECS / EKS のベースイメージを更新し、スケールアウトで脆弱な個体が復活しないよう固定化する

ALAS → SSM → 修正版適用 → Inspector → AMI 再ビルド、という流れです。カーネル脆弱性のときと骨格は同じで、違いは「ミドルウェアなのでアプリ層の互換性確認が一段増える」点にあります。

今回のCVEで実際にやったこと

業務で運用している EC2 上の Apache でも、今回の対応を入れました。やったことはシンプルで、本記事の暫定対応（該当ホストでの HTTP/2 無効化）を入れたうえで、OS パッケージを修正版へアップデートし、Apache を再起動しただけです。適用前後で apachectl configtest と主要エンドポイントのスモークテストを回しましたが、結果として特段のトラブルは起きませんでした。

正直に書くと、今回は「ハマりポイント」と呼べるものは特になく、淡々と当てて終わり、という対応でした。逆に言えば、下にまとめた運用上の勘所さえ押さえておけば、この手のミドルウェア CVE は落ち着いて処理できます（業務環境の構成・規模などの詳細は伏せます）。

業務での運用感

Apache のメジャーアップデートが原因で動かなくなる確率は、経験的には低めです。とはいえ、過去にはハマりどころもあったので、運用上の勘所を整理しておきます。

互換性で挙動差が出やすいポイント

mod_security や独自の mod_rewrite ルール、SSL 設定（特に SSLProtocol / SSLCipherSuite の警告）まわりで微妙な挙動差が出ることはありました。ミドルウェアの脆弱性対応では、パッチを当てて終わりではなく、アプリ層の設定と整合しているかの確認が欠かせません。

本番適用前の検証フロー

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

AMI 更新漏れに注意

加えて、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 を併読することをおすすめします。

関連記事

同じ AWS 上の脆弱性対応でも、レイヤーによって勘所が変わります。あわせて読むと、対応フローの共通点と違いが見えてきます。

両者は重複ではなく補完関係です。ざっくり言うと、

  • カーネル脆弱性（Copy Fail）は、OS パッケージの自動パッチ適用が中心で、適用後はリブートで完結しやすい
  • ミドルウェア脆弱性（今回の Apache）は、パッチ適用に加えてアプリ層（mod_rewrite / mod_security / SSL 設定など）との互換性確認が必須

という違いがあります。AWS 側の起点（ALAS → SSM → Inspector → AMI 再ビルド）は共通なので、片方の対応経験はもう片方にそのまま活かせます。

関連記事

← 記事一覧に戻る