Apache HTTP Server 2.4の脆弱性まとめ：CVE-2026-33523ほか2.4.67/2.4.68の影響範囲と対応手順

2026年5月4日、Apache HTTP Server 2.4系に複数の脆弱性が公表され、修正版の2.4.67がリリースされました。CVE-2026-33523（HTTPレスポンス分割）をはじめ、HTTP/2のリモートコード実行につながりうるCVE-2026-23918、共有ホスティングで問題になる権限昇格のCVE-2026-24072など計11件で、いずれも2.4.66以前のすべてのバージョンが影響を受けます。さらに6月8日には追加の脆弱性を修正した2.4.68も公開されました。本記事では各CVEの深刻度と影響モジュール、自社環境が該当するかの判定方法、ディストリビューション別のパッチ適用手順、PoC・悪用状況、暫定対応までを実務目線で整理します。

まとめ：最優先は最新版（2.4.68）への更新

• 結論は「2.4.68へ更新」。5月の2.4.67で11件、6月8日の2.4.68でさらに13件が修正されており、いま上げるなら最新の2.4.68が無駄がありません。
• 最も危険なのはCVE-2026-23918（mod_http2、CVSS 8.8）。HTTP/2を有効にした既定構成でサービス停止（DoS）が容易に起こり、条件次第でリモートコード実行に至ります。今回唯一のRCE級です。
• 影響バージョンは2.4.0〜2.4.66。httpd -v でバージョンを、httpd -M で有効モジュールを確認すれば該当有無を判断できます。
• mod_proxy_ajp関連の4件（CVE-2026-28780ほか）は、攻撃者が制御するAJPバックエンドが前提で、一般的な公開構成では実害リスクは低めです。
• すぐにパッチを当てられない場合は、未使用モジュールの無効化やWAFでの暫定対応で時間を稼ぎます。

以下、CVE一覧と深刻度→該当判定→更新手順→悪用状況→暫定対応の順に掘り下げます。

2.4.67で修正されたCVE一覧と深刻度の比較

2.4.67で修正された11件を、Apacheの深刻度評価・影響モジュール別に整理します。深刻度は同じ「低」でも前提条件や影響が異なるため、まず全体像を把握してから自社に関係するモジュールを見極めるのが効率的です。CVSSや深刻度評価の読み方そのものはCVEの基本的な定義と重要性の解説もあわせて参照してください。

「低」が並びますが、悪用の前提条件が緩いものほど現実の優先度は上がります。以下、対応判断に直結する主要CVEを個別に補足します。

最優先の重大脆弱性：CVE-2026-23918（HTTP/2のRCE）

mod_http2のストリーム後処理（h2_mplx.c）に存在する二重解放です。クライアントがHTTP/2のHEADERSフレーム直後に同一ストリームへRST_STREAMを送ると、マルチプレクサがストリームを登録する前に解放処理が二重で走ります。CVSSは8.8。mod_http2とマルチスレッドMPMを使う既定構成なら、攻撃者はこのフレーム列を送るだけでサーバをクラッシュさせられます。リモートコード実行はAPRがmmapアロケータを使う環境（Debian系の既定）で成立条件が整い、解放済みアドレスに偽のストリーム構造体を配置する手口が報告されています。HTTP/2は広く有効化されているため攻撃面が大きく、今回のバッチで唯一RCEに至りうる脆弱性です。

権限昇格：CVE-2026-24072（mod_rewrite・共有ホスティング）

mod_rewriteなどが解釈する式言語（ap_expr）を悪用し、.htaccessを書ける利用者がhttpd実行ユーザー権限で他アカウントのファイルを読み取れる問題です。利用者に.htaccessの編集権限を与える共有ホスティングやマルチテナント環境では、テナント間のファイル越境につながるため深刻度は「中」でも実務上の影響が大きい一件です。

認証バイパス：CVE-2026-33006（mod_auth_digest）

mod_auth_digestのダイジェスト認証にタイミング攻撃の余地があり、応答時間の差から認証を回避される可能性があります。ダイジェスト認証を利用している場合のみ該当します。Basic認証や外部の認証基盤に寄せている構成では直接の影響はありません。

HTTPレスポンス分割：CVE-2026-33523（複数モジュール）

対策キーワードにもなっているCVE-2026-33523は、mod_proxy_uwsgiやmod_proxy_httpなど複数のモジュールが、バックエンドから受け取ったステータス行を検証せずクライアントへ転送することで起きるHTTPレスポンス分割です。CVSSは6.5。攻撃者がバックエンドを制御できる状況で、細工したヘッダーを注入してキャッシュ汚染やヘッダーインジェクションを引き起こします。信頼できないバックエンドをリバースプロキシ経由で公開している構成が前提条件です。

mod_proxy_ajp系の連続的な欠陥（28780・33857・34032・34059）

4件はいずれもmod_proxy_ajpのAJPメッセージ解析に起因します。CVE-2026-28780はヒープバッファ溢れ（バッファ末尾に4バイトの書き込み）、33857は境界外の1バイト読み取り、34032と34059は文字列終端の検査漏れによる境界外読み取りとメモリ情報漏えいです。いずれも攻撃者が制御するAJPバックエンドサーバが前提で、TomcatなどへAJPで中継する構成かつバックエンドが侵害されている場合に成立します。AJPを使っていない、または信頼できる内部バックエンドのみの構成では現実的なリスクは限定的です。

影響を受けるバージョンと自社環境の該当判定

影響範囲は2.4.0から2.4.66までで、2.4.67以降で修正済みです。ただし「バージョンが該当する」ことと「実際に攻撃可能」はイコールではありません。多くのCVEは特定モジュールが有効な場合にのみ影響するため、バージョンと有効モジュールの両方を確認して判断します。

稼働中のバージョンを確認する

まず実行中のApacheのバージョンを確認します。2.4.66以前なら、後述のモジュール確認に進みます。

httpd -v
apachectl -v

Debian/Ubuntu系ではコマンド名が apache2 になります。表示が Server version: Apache/2.4.xx の形式で出るので、末尾の番号を確認してください。

有効なモジュールから影響有無を判定する

次に有効なモジュールを一覧表示します。今回のCVEは http2・proxy_ajp・rewrite・auth_digest・dav_lock・authn_socache・md のいずれかに紐づくため、出力に該当モジュールがあるかで影響範囲を絞り込めます。

httpd -M
apachectl -M

たとえば http2_module が出力に含まれていればCVE-2026-23918の対象、proxy_ajp_module が無ければAJP系4件は無関係、と判断できます。使っていないモジュールは無効化することで攻撃面そのものを減らせます。

最新版（2.4.68）への更新とディストリ別のパッチ適用

5月の2.4.67で11件を修正した後、6月8日には2.4.68が公開され、HTTP/2のメモリ枯渇DoS（CVE-2026-49975）やmod_ldapの解放後参照（CVE-2026-29167）など追加で13件が修正されました。これらは2.4.67以前が影響するため、これから更新するなら2.4.67を飛ばして2.4.68へ上げるのが合理的です。GSCでも「apache 最新バージョン」の流入が一定数あり、最新を求める読者が多い領域です。

ディストリ別の更新とバックポートの注意点

本番環境では公式ソースのビルドよりも、ディストリビューションのパッケージで運用しているケースがほとんどです。各ディストリは安定版のバージョン番号を据え置いたまま修正だけを取り込むバックポートを行うため、httpd -v の表示が2.4.66のままでも、パッケージとしては修正済みということが起こります。バージョン文字列ではなくパッケージのリビジョンとセキュリティ告知で判断してください。

sudo apt update && sudo apt install --only-upgrade apache2
sudo dnf upgrade httpd
sudo yum update httpd

Ubuntuはセキュリティ通知（USN）、RHEL系・Amazon LinuxはErrata（RHSA／ALAS）で該当パッケージの配布状況を確認できます。GSCでもCVE-2026-23918に「ubuntu」「rhel」「amazon linux」を付けた検索が見られ、配布元ごとのパッチ提供時期を気にする運用者が多いことがわかります。配布が間に合わない期間は次章の暫定対応で埋めます。

攻撃の実現性とPoC・悪用状況

「低」が多いバッチですが、深刻度ラベルだけで横並びに扱うと優先順位を誤ります。実際に守るべき順番は、悪用の前提条件で大きく変わります。

明確に最優先なのはCVE-2026-23918です。DoSはHTTP/2を有効にしただけの既定構成で成立し、特別な前提を必要としません。インターネットに面したApacheでHTTP/2を使っているなら、ここだけは即時対応の対象と考えるべきです。一方、mod_proxy_ajpの4件は実環境での危険度が相対的に低いです。成立にはAJPバックエンド自体を攻撃者が制御している必要があり、これは「すでに内部のTomcatが乗っ取られている」状況に近く、その時点で別の重大インシデントだからです。CVE-2026-33523やCVE-2026-24072も、それぞれ「信頼できないバックエンドの公開」「利用者への.htaccess編集権限付与」という構成条件が前提になります。

PoCの公開状況は時間とともに変わります。本稿執筆時点で兵器化された一般公開のエクスプロイトは広くは出回っていませんが、23918のように技術的詳細が解説されている脆弱性は概念実証が早期に出やすい傾向です。最新の悪用状況はJPCERT/CCやApache公式の告知で都度確認してください。過去のApache HTTP Serverの脆弱性でも、パストラバーサル（CVE-2021-41773/42013）のように公表直後から実際の探索行為が観測された例があり、「低」でも放置を前提にはできません。

パッチを即時適用できない場合の暫定対応

検証や再起動の都合ですぐに更新できない場合は、攻撃面を一時的に縮小して時間を稼ぎます。恒久対応はあくまでパッチ適用である点を前提に、以下を併用します。

• 未使用モジュールの無効化：AJPやダイジェスト認証を使っていなければ proxy_ajp_module・auth_digest_module を無効化し、該当CVEを構成上無効化する。
• HTTP/2の一時停止：23918が懸念で更新が間に合わない場合、暫定的にHTTP/2を切ってHTTP/1.1運用に戻す（性能とのトレードオフは要評価）。
• WAF・リバースプロキシでの遮断：異常なHTTP/2フレーム列や不正なヘッダーを検知・遮断するルールを前段で適用する。レスポンス分割系はバックエンド由来ヘッダーの検査が有効。

いずれも応急処置であり、攻撃手法の更新で回避され得ます。配布パッケージが整い次第、速やかに2.4.68へ更新してください。

よくある質問（FAQ）

Q. 2.4.67と2.4.68のどちらに上げるべきですか。
これから更新するなら2.4.68です。2.4.68は2.4.67で直した11件に加え、HTTP/2のメモリ枯渇DoSなど13件を追加で修正しており、2.4.67を経由する利点はありません。

Q. mod_proxy_ajpを使っていなければ安全ですか。
AJP系の4件（28780・33857・34032・34059）は無関係になりますが、HTTP/2のCVE-2026-23918やレスポンス分割のCVE-2026-33523は別モジュールの問題です。httpd -M で有効モジュールを確認し、バージョンが2.4.66以前なら更新が前提です。

Q. ディストリのバージョンが2.4.66のままですが、未対応ということですか。
必ずしもそうではありません。多くのディストリはバージョン番号を据え置いて修正だけを取り込むバックポートを行います。バージョン文字列ではなく、パッケージのリビジョンとセキュリティ告知（USN／RHSA／ALAS）で対応状況を確認してください。

Q. PoCや実際の攻撃は出ていますか。
本稿執筆時点で広く出回る兵器化エクスプロイトは確認されていませんが、状況は変動します。特にCVE-2026-23918は優先的に対応し、最新動向はJPCERT/CCやApache公式で確認してください。

Q. Apache TomcatとApache HTTP Serverは同じものですか。
別製品です。本記事の対象はWebサーバのApache HTTP Server（httpd）で、JavaサーブレットコンテナのApache Tomcatとは脆弱性も対応も異なります。AJP（mod_proxy_ajp）はApache HTTP ServerからTomcatへ中継する際に使われる接続点で、両者をつなぐ箇所として登場します。

関連記事

• Apache HTTP Serverにおけるパストラバーサル脆弱性（CVE-2021-41773/CVE-2021-42013）の概要
• NGINX Rift（CVE-2026-42945）が緊急とされる理由と発見の経緯
• 「7-Zip」脆弱性の全体像と2025年以降に公表された主要CVE一覧
• CVEとは？基本的な定義とセキュリティ分野での重要性について