Apache HTTP Server の脆弱性｜影響確認と更新判断

はじめに

2026 年 10 月 1 日、Apache HTTP Server Project は Apache HTTP Server 2.4.69 を公開し、2.4 系の脆弱性 20 件の修正を公表しました。翌 10 月 2 日には、JPCERT/CC と IPA が運営する JVN も JVNVU#94648869 として本件を掲載しています。

今回の 20 件は、HTTP/2、WebDAV、CGI、Digest 認証、プロキシなど、特定のモジュールや設定を使う構成で成立するものが大半です。一方で、Ubuntu などの OS パッケージは修正をバックポートするため、更新後も版番号が 2.4.69 にならない場合があります。CVE の件数や版番号だけでは、自環境の対応要否と対応完了を判断できません。

結論として、上流のソースや独立配布のバイナリで運用している httpd は、2.4.69 への更新が対処です。OS パッケージ、コンテナー、同梱製品は、配布元が CVE ごとに示す状態と修正済みの版で判定します。執筆時点（2026 年 10 月 3 日）の Ubuntu 24.04 LTS は、20 件とも配布元による影響の評価が完了しておらず、修正版も提供されていません。いずれの場合も、修正されたコードを読み込んだプロセスが稼働していることまで確認して、対応完了とします。

Apache HTTP Server 2.4.69 で修正された脆弱性

公式一覧では、2.4.69 で修正された脆弱性は 20 件で、Apache の深刻度は moderate が 5 件、low が 15 件です。修正版はいずれも 2.4.69 で、影響版は多くが 2.4.0〜2.4.68 です（例外は一覧に記載）。なお、Apache Tomcat は別製品のため、今回の HTTP Server の更新対象には含まれません。Tomcat の 2026 年 9 月の脆弱性は『Apache Tomcat の脆弱性｜構成別の影響確認と更新判断』で扱っています。

公表から執筆時点までの経緯

Apache による公表日（10 月 1 日）と JVN の公開日（10 月 2 日）は異なります。各機関の掲載状況は次のとおりです。

修正対象 20 件の一覧

CVE 欄には Apache の深刻度を併記しています。成立条件は公式説明に記載された範囲で整理し、詳細条件が公表されていない項目はその旨を記載しました。OS を限定しているのは CVE-2026-59685（Windows）のみです。

Apache の深刻度と CVSS の違い

low / moderate は Apache セキュリティチームによる影響評価で、CVSS のスコアではありません。Apache 自身も、この評価は動作環境によって変わり得ると説明しています。

参考: Apache HTTP Server 2.4 vulnerabilities
“this rating may well vary from platform to platform”
（この評価はプラットフォームによって異なる可能性がある）
https://httpd.apache.org/security/vulnerabilities_24.html

CVE Record で CISA-ADP が付与した CVSS 3.1 の基本値は、Apache が low とした CVE-2026-56154（mod_rewrite）と CVE-2026-59797（mod_ssl）、moderate とした CVE-2026-57941（mod_http2）がいずれも 9.8 です。Ubuntu は 20 件すべての優先度を Medium としています。評価主体ごとに前提が異なるため、low という分類だけで対応不要と判断せず、該当する機能を使っているかで優先度を決めることを推奨します。

悪用状況と KEV 登録

執筆時点で、20 件の悪用を示す公式情報は確認できていません。CISA-ADP の SSVC は 10 月 1 日時点で 20 件とも Exploitation が none で、KEV カタログ 2026.10.02 版にも登録はありません。悪用状況は「未確認」として扱い、公表後の更新を継続して確認してください。

CVE-2026-42528 の影響版の表記差

CVE-2026-42528（mod_dav）は、公式の説明文では 2.4.67 以前、Affects 欄では 2.4.68 までが影響版と記載されています。CVE Record の影響版データも 2.4.68 以下を affected としており、Apache 担当者による oss-security への告知にも同じ差があります。執筆時点で差異は解消されていないため、2.4.68 を修正済みとは扱わず、2.4.69 を基準に判断することを推奨します。

利用モジュールと設定から影響を確認する

影響の確認は、稼働している httpd の特定、設定で読み込むモジュール、有効な設定の順に進めます。本記事のコマンドは、Ubuntu 24.04 LTS の apache2 パッケージと上流ソースからのビルドを想定した説明例で、実機での出力結果ではありません。

稼働中の httpd とモジュールを特定する

まず、実際にサービスを提供しているプロセスと実行ファイルを確認します。OS パッケージ版と、ソースからビルドした版（既定の配置先は /usr/local/apache2）が同じサーバーに共存している場合、手元で実行したコマンドが稼働中とは別の httpd を調べている可能性があります。

systemctl status apache2

表示されるプロセスのコマンドラインで、実行ファイルのパス（Ubuntu のパッケージでは /usr/sbin/apache2）を確認します。Ubuntu では起動に /etc/apache2/envvars の環境変数が必要なため、実行ファイルを直接呼び出さず、apache2ctl 経由で httpd のオプションを渡します。

参考: httpd – Apache Hypertext Transfer Protocol Server
“currently only shows the virtualhost settings”
（-S は現状、VirtualHost の設定のみを表示する）
https://httpd.apache.org/docs/2.4/programs/httpd.html

sudo apache2ctl -V
sudo apache2ctl -M
sudo apache2ctl -S

-M と -S の表示は、コマンドの実行時にディスク上の設定ファイルを読み込んで解析した結果です。稼働中のプロセスの内部状態を直接取得するものではないため、設定を変更した後に reload や restart をしていない場合は、表示結果と稼働中の状態が異なる可能性があります。設定ファイルの更新日時と、プロセスの起動時刻や、最後に reload・restart を実行した時刻もあわせて確認してください。

ソースからビルドした httpd では、/usr/local/apache2/bin/apachectl -V のように、稼働中の実行ファイルと同じ配置先のコマンドを使います。apache2ctl の動作は Ubuntu の apache2ctl マニュアルで確認できます。

有効な設定を Include と .htaccess まで確認する

-M で設定上読み込まれるモジュールを確認したら、成立条件に関わるディレクティブが有効な設定に含まれているかを確認します。Ubuntu では /etc/apache2/apache2.conf から sites-enabled や conf-enabled 配下が読み込まれるため、/etc/apache2 全体を検索します。

sudo grep -RniE 'VirtualDocumentRoot|LimitRequestFieldSize|Protocols|^\s*Dav|AuthDigest|UserDir|ProxyRequests|SSLRequire|LA-U|SessionCookieRemove' /etc/apache2/

grep は文字列の一致を表示するだけのため、コメントアウトされた行や、有効化していないサイトの設定も表示されます。表示された行が実際に読み込まれる設定かを確認してください。また、AllowOverride で上書きを許可したディレクトリでは、.htaccess に設定が書かれている可能性があります。

sudo find /var/www -name .htaccess

/var/www は Ubuntu の既定の DocumentRoot を含むディレクトリの例です。実際の DocumentRoot や、UserDir などで公開しているディレクトリに置き換えてください。

CVE-2026-63292（mod_vhost_alias）の照合

mod_vhost_alias をロードしているだけでは、成立条件を満たしません。公式説明では、VirtualDocumentRoot がホスト名の書式指定子を使い、かつ LimitRequestFieldSize が既定値より引き上げられている場合に、8192 バイトを超える Host ヘッダーで成立するとされています。2 つの設定がそろっているかを照合してください。

参考: oss-security（CVE-2026-63292 の告知）
“potentially execute arbitrary code”
（任意のコードを実行できる可能性がある）
https://seclists.org/oss-sec/2026/q4/23

公式に記載された影響は DoS と任意コード実行の可能性で、任意コード実行は確定した影響として示されていません。ただし、2 つの設定がそろう構成では、DoS に限定せず更新の優先度を上げることを推奨します。公式はどの書式指定子が該当するかを列挙していないため、VirtualDocumentRoot でホスト名に由来する値を使っていれば、対象として扱うことを推奨します。

CVE-2026-42356（CGI の内部リダイレクト）の照合

影響版は 2.4.60〜2.4.68 です。CGI プログラムが発生させた内部リダイレクトの転送先が、CGI を有効にしたディレクトリ内にあり、mod_mime が解釈する他の拡張子を持たない場合に、その転送先も CGI として実行されます。公式タイトルは「limited RCE」で、Apache を使う全環境で認証不要の任意コード実行が成立するものではありません。

参考: oss-security（CVE-2026-42356 の告知）
“The target must already be in a directory enabled for CGI”
（転送先は、CGI が有効なディレクトリに既に存在している必要がある）
https://seclists.org/oss-sec/2026/q4/10

確認対象は、設定で cgi_module または cgid_module を読み込んでいるか、ScriptAlias や Options の ExecCGI で CGI を有効にしたディレクトリ、そのディレクトリ内の CGI プログラムが内部リダイレクトを返すかの 3 点です。あわせて、CGI 有効ディレクトリに拡張子のないファイルが置かれていないか、第三者がファイルを配置できる経路がないかも確認することを推奨します。これは公式の成立条件から編集上整理した確認項目です。

CVE-2026-57941（HTTP/2）の照合

公式説明は mod_http2 の session->bbtmp の再入による Use After Free とのみ記載しており、詳細な成立条件は公表されていません。そのため、Apache が HTTP/2 を提供しているかを基準に確認します。mod_http2 はロードするだけでは HTTP/2 を提供せず、Protocols ディレクティブでの有効化が必要です。

参考: Apache Module mod_http2
“You must enable HTTP/2 via Protocols”
（HTTP/2 は Protocols で有効化する必要がある）
https://httpd.apache.org/docs/2.4/mod/mod_http2.html

確認するのは、-M の表示に http2_module が含まれるか、Protocols に h2（TLS）または h2c（平文）を含む VirtualHost の有無、実際の接続区間の 3 点です。前段の CDN やロードバランサーが HTTP/2 に対応していても、Apache との間を HTTP/1.1 で接続していれば、その区間で Apache は HTTP/2 を提供していません。一方、TLS をパススルーする構成や、前段から Apache へ HTTP/2 で接続する構成では、Apache 側の HTTP/2 が使われます。前段の対応状況ではなく、Apache が受ける接続で判断してください。

curl --http2 -s -o /dev/null -w '%{http_version}\n' --resolve www.example.com:443:192.0.2.10 https://www.example.com/

上記は前段を経由せず、Apache の IP アドレス（例では 192.0.2.10）へ直接接続する例です。HTTP/2 で接続できた場合は 2、HTTP/1.1 の場合は 1.1 と表示されます。アクセスログの LogFormat に %H（リクエストのプロトコル）を含めておけば、実際の通信で使われたプロトコルも確認できます。

過去の HTTP/2 の脆弱性 CVE-2026-49975 は 2.4.68 で修正されたもので、『Apache HTTP/2 Bomb とは｜CVE-2026-49975 の影響範囲と対処』で解説しています。CVE-2026-49975 の修正を適用済みであることは、CVE-2026-57941 の修正を意味しません。

WebDAV（mod_dav / mod_dav_fs）の照合

WebDAV 関連の 3 件は、必要な権限と影響が異なります。設定で dav_module と dav_fs_module を読み込んでいるかに加え、Dav On を設定した場所と、そこで操作を許可している利用者の範囲を CVE ごとに確認します。

• CVE-2026-42528: ロックの作成（LOCK）を、認証の有無を含めてどの利用者に許可しているか。
• CVE-2026-93546: 書き込み権限を持つ認証済み利用者の範囲。プロパティ DB の永続的な破損が影響に含まれるため、更新後もプロパティの状態とバックアップを確認対象に含めることを推奨します。
• CVE-2026-58415: WebDAV 領域内の .DAV 状態ディレクトリへ、外部から GET で到達できるか。dead property に業務上の情報を保存していないか。

Windows・Digest 認証・プロキシ・.htaccess の確認ポイント

上記以外の CVE は、該当する構成を運用している場合に、次の観点で設定を確認します。

Windows で運用している場合

CVE-2026-59685 は Windows 上の 8.3 形式名の処理で成立します。Apache は Windows 用のバイナリを配布しておらず、第三者の配布元から入手する形式のため、利用中の配布元が 2.4.69 ベースの版を提供しているかを確認します。

Digest 認証を使っている場合

mod_auth_digest の 3 件は、AuthDigestNcCheck の有効化と AuthDigestNonceLifetime 0 の組み合わせによって、該当する CVE が変わります。両ディレクティブの設定値を VirtualHost や Directory ごとに確認します。

プロキシとして使っている場合

ProxyRequests On のフォワードプロキシで mod_proxy_ftp を使う構成と、mod_proxy_uwsgi、mod_proxy_html、mod_xml2enc で細工された応答を受ける可能性がある構成が対象です。設定で読み込んでいるプロキシ関連モジュールと、転送先のバックエンドの管理主体を確認します。

.htaccess を利用者に開放している場合

CVE-2026-59797 は、.htaccess での SSLRequire とファイル関連の式に関する権限管理の不備です。AllowOverride で .htaccess の記述を別部門や第三者に許可している環境では、優先して確認します。

その他のモジュール

mod_rewrite のルックアヘッド、mod_session_cookie、mod_userdir、mod_heartmonitor、mod_charset_lite は、一覧の成立条件に沿って、モジュールの読み込みと設定を確認します。mod_charset_lite のように詳細条件が公表されていない項目は、設定で読み込んでいれば更新対象として扱います。

導入方法別に修正済みかを判断する

修正済みかの判断材料と、更新を実施する主体は導入方法によって異なります。上流の版番号 2.4.69 がそのまま判断基準になるのは、上流のソースを自らビルドしている場合など、上流の版をそのまま使う配布形態に限られます。

上流のソースと変更履歴（CHANGES_2.4.69）は、公式のダウンロードページから確認できます。

バックポートと版番号の関係

OS の配布元は、上流の新しい版へ移行せず、提供中の版に修正だけを取り込む（バックポート）ことが一般的です。Red Hat はバックポートの方針について、パッケージの版番号だけでは脆弱かどうかを判断できないと説明しています。

参考: Red Hat（Backporting Security Fixes）
“will not tell them if they are vulnerable or not”
（版番号を見るだけでは、脆弱かどうかは分からない）
https://access.redhat.com/security/updates/backporting

そのため、Ubuntu 24.04 LTS の apache2 が 2.4.58 と表示されても、修正済みの場合があります。ただし、バックポートの有無と時期は CVE ごとに異なり、配布元が一部の CVE を対象外や修正延期とすることもあります。OS を更新すれば 20 件すべてに対応できるとは限らないため、対象 OS・リリース・CVE・パッケージのリビジョンを含む版を照合する必要があります。

Ubuntu 24.04 LTS での照合手順

Ubuntu 24.04 LTS（noble）の apache2 を例に、修正状況の照合手順を示します。Ubuntu の apache2 の導入と設定ファイルの配置は、『Apache とは｜Ubuntu へのインストールと HTTPS 化の手順』も参考にしてください。

apt-cache policy apache2-bin

2026 年 10 月 3 日（日本時間）に、Canonical が公開する Ubuntu 24.04 LTS の VEX データ（各 CVE の更新は 2026 年 10 月 2 日 20 時台、UTC）で、apache2 の 20 件の状態を CVE ごとに照合しました。20 件とも状態は under_investigation で、affected（Vulnerable）、fixed（Fixed）、not_affected（Not affected）はありませんでした。Ubuntu の資料では、under_investigation は Web 上の Needs evaluation と Vulnerable, fix deferred の両方に対応します。今回のデータでは両者を区別する補足がないため、Web 上の表示は CVE ページで確認してください。

修正版の記載がないことは、20 件すべてに影響があることを意味しません。Needs evaluation の CVE は影響未判定として、記事前半で確認した自環境の構成と照らし合わせます。該当する機能を使っている CVE は、配布元の判定を待つ間も暫定対応の対象に含めることを推奨します。Vulnerable と判定された CVE は修正版未提供として扱い、暫定対応と継続管理の対象にします。状態のデータ形式は Ubuntu VEX data に記載されています。

修正版が未提供の場合と暫定対応

配布元の Advisory が未公開、または影響を評価中の場合は影響未判定として、影響ありと判定されたが修正版が未配信の場合は修正版未提供として、次の確認先を継続して確認します。状態が変わった時点で、該当する手順へ進みます。

• OS パッケージ: 配布元の CVE トラッカーとセキュリティ告知（Ubuntu では CVE ページと USN）
• コンテナーイメージ: イメージ提供元の更新情報と、タグ・ダイジェストの更新
• 同梱製品: 製品提供元のセキュリティ告知とサポート窓口

修正版未提供の CVE と、影響未判定でも自環境が該当機能を使っている CVE は、該当機能の停止や設定の見直しで、対象 CVE の成立条件を減らす方法があります。例として、HTTP/2 を使わない VirtualHost で Protocols から h2 / h2c を外す、LimitRequestFieldSize を既定値に戻す、WebDAV のロックと書き込みを必要な利用者に限定する、使っていないモジュールを設定から読み込まないようにする、といった対応です。

これらは個別の CVE の成立条件を外す対応で、修正の代わりにはなりません。機能の停止は業務影響を伴うほか、詳細条件が公表されていない CVE-2026-56153 のように、設定だけでは照合しにくい項目も残ります。また、ServerTokens によるバージョン表示の抑制や WAF の設置は、脆弱なコード自体を修正するものではありません。

コンテナーと同梱製品の場合

コンテナーでは httpd がイメージに含まれるため、ホスト OS のパッケージを更新しても、コンテナー内の httpd は変わりません。修正版を含むベースイメージや httpd イメージを確認したうえでイメージを再作成し、再デプロイして稼働中のコンテナーを置き換えます。稼働中のコンテナーが、新しいイメージのダイジェストで起動していることまで確認します。

製品やアプライアンスに同梱された httpd は、更新方法とサポート範囲を製品の提供元が定めるため、提供元の告知に従います。ホスト OS の更新だけで対応完了とはせず、同梱先ごとに修正状況を管理します。

更新前後の確認と対応完了の基準

更新作業は、事前準備、更新と再起動、更新後の確認の順に進めます。ここでは、Ubuntu 24.04 LTS で修正版のパッケージが提供された後の手順を例に示します。

更新と再起動の手順

sudo tar czf /root/apache2-conf-backup.tar.gz /etc/apache2

sudo apache2ctl -t

sudo apt update && sudo apt upgrade

sudo apache2ctl -t

sudo systemctl restart apache2

apachectl -k restart と systemctl restart の違い

Apache の公式資料では、apachectl -k graceful と apachectl -k restart はいずれも親プロセスへ送るシグナルで、親プロセスが設定ファイルを読み直す動作として説明されています。apachectl -k restart でも、親プロセス自体は終了しません。

参考: Stopping and Restarting Apache HTTP Server
“the parent doesn’t exit”
（apachectl -k restart の説明。親プロセスは終了しない）
https://httpd.apache.org/docs/2.4/stopping.html

reload、graceful、apachectl -k restart の成功を、更新したバイナリの反映確認とみなさないでください。一方、手順で使う sudo systemctl restart apache2 は、systemd が apache2 のサービスを停止してから起動する操作で、apachectl -k restart とは動作が異なります（systemctl のマニュアル）。配布元の手順に沿って再起動または再デプロイし、プロセスの起動時刻がパッケージの更新より後であることを確認します。

ps -o pid,lstart,cmd -C apache2

表示された各プロセスの起動時刻（lstart）が更新を実施した時刻より後であれば、更新後に起動したプロセスです。ソースからビルドした httpd では、稼働中の実行ファイルで -v を実行し、2.4.69 と表示されることもあわせて確認します。

更新後の確認項目

修正状況と稼働状態に加え、利用中の機能が更新前と同じように動作するかを確認します。

対応完了の基準と切り戻し

対応完了は、次の条件をすべて満たした状態とします。

• 稼働中の httpd を、ホスト、コンテナー、同梱製品ごとに洗い出している。
• 配布元が Fixed とした CVE は修正版以上、Not affected とした CVE は理由を確認済み、上流版は 2.4.69 以降を導入している。
• 修正版を読み込んだプロセスやコンテナーが稼働している。
• 主要 URL と利用中の機能の動作を確認している。

影響未判定や修正版未提供の CVE が残る間は、対応完了とはしません。CVE ごとの状態、自環境の該当有無、暫定対応の内容を記録し、配布元の状態が変わった時点で改めて照合します。

更新後の不具合で未修正の版へ切り戻すと、今回の脆弱性も再び残ります。切り戻した場合は、該当機能の暫定対応を確認し、修正版を再適用する時期を決めておくことを推奨します。

まとめ

Apache HTTP Server 2.4.69 で修正された 20 件は、大半が特定のモジュールや設定を使う構成で成立します。影響は版番号ではなく稼働中の httpd と有効な設定を基準に確認し、修正状況は導入方法ごとの配布元で照合することが重要です。

• 2026 年 10 月 1 日公開の 2.4.69 で、脆弱性 20 件を修正
• Apache の深刻度は moderate 5 件と low 15 件で、CVSS とは別の評価
• 執筆時点で、悪用の情報と KEV への登録は確認できていません。
• HTTP/2、WebDAV、CGI などの利用有無と設定値で影響を照合
• OS パッケージはバックポートのため、CVE ごとに修正版を確認
• 執筆時点の Ubuntu 24.04 LTS は 20 件とも評価中で、修正版も未提供
• サービスを停止・起動し、修正版のプロセスの稼働まで確認

以上、最後までお読みいただきありがとうございました。