Apacheに最上位評価の脆弱性、10月に上げた2.4.69も対象

10月に2.4.69へ上げたApacheも、今回はまた対象に入ります。Apache HTTP Server Projectは11月11日に2.4.71を公開し、HTTP/2を受け持つモジュールmod_http2の脆弱性CVE-2026-119618を修正しました。公式の評価は4段階でいちばん上の「critical」で、説明には「can lead to RCE」とあります。

対象は2.4.55から2.4.70まで。ただ、実際に当たるかどうかは、HTTP/2を使っているかで分かれるとみられます。Apacheはそこまで書いていませんが、脆弱性はHTTP/2を受け持つモジュールの中にあります。

2.4系で3件目の「critical」

Apacheの2.4系の脆弱性のページには、評価付きのCVEが182件並んでいます。いちばん多いのはlowの89件で、criticalは今回を入れて3件しかありません。前の2件は、2021年10月のパス・トラバーサルでした。¹

2021年の2件と比べると、範囲の広さがまるで違います。2021年の対象は2.4.49と2.4.50だけでしたが、1件目には公式のページに「known to be exploited in the wild」と書かれました。今回の範囲は2023年1月の2.4.55から先のすべてで、Debian 12や13の標準の版もこの中です。それより前で止まった台はこの1件から外れますが、10月に修正されたmod_http2の別の脆弱性などを抱えたままです。

悪用の報告は、12日朝の時点で見当たりません。Apacheのページに悪用の記載はなく、JPCERT/CCとIPAも注意喚起を出していません。CISAのKEVは、最新版が公表より前の11月10日版でした。

最初に報告したのはAnthropicのOSS Scannerで、10月26日のこと。11月3日には、Google Cloudの脆弱性研究チームも同じものを報告しました。KEVに載ったApacheの2.4系の脆弱性は4件あり、うち2件はApacheの評価がimportantです。²最上位の評価でなくても悪用された前例があり、別々のチームが8日違いで同じ脆弱性にたどり着いたことも考えると、悪用の確認を待ってから動く理由は薄いとみています。攻撃の条件の細かい中身は、SecPulseのCVE-2026-119618のページで読めます。

HTTP/2の設定で、影響を受ける台を見分ける

Apacheの手引きによると、HTTP/2が動くのは、LoadModuleでmod_http2を読み込み、Protocolsに「h2」か「h2c」を書いたときです。Protocolsの既定はhttp/1.1だけなので、h2もh2cも書かれていなければ、HTTP/2は出ていません。

この2つの条件は、同じ重さではありません。モジュールを読み込んでいない台なら、この1件が起きる道はないとみられます。

Protocolsからh2とh2cを外しただけの台は、HTTP/2の通信が始まらないので、当たりにくいでしょう。ただ、モジュールは読み込まれたままで、Apacheはどちらの場合にも触れていません。

2.4.71で修正された3件は次のとおりです。

2.4.69と2.4.70なら、3件すべての範囲に入ります。HTTP/2を止めているサーバーでも、mod_mdかmod_vhost_aliasを使っていれば、更新の理由は残るわけです。

mod_mdはACMEで証明書を取得し、更新まで受け持つモジュール。CVE-2026-106023では、HTTPのリクエストを処理する途中でNULLポインタを参照し、子プロセスが落ちます。Let's Encryptなどの証明書をApache自身に取らせている会社なら、HTTP/2の有無にかかわらず、この1件も気にしておきたいところです。

lowの1件は、題に10月の脆弱性の番号を挙げて「after」と付けています。10月の2.4.69で修正されたmod_vhost_aliasの脆弱性のことで、対象は10月の版とその次の版だけ。その修正のあとに入った不具合と読めます。10月の20件の内訳は、Apache HTTP Serverに脆弱性20件、修正版2.4.69。版と使用モジュールを確認で確認できます。

外からの見え方だけで決めるのは危ういでしょう。CDNやnginxを前に置いた構成なら、外にHTTP/2で応答しているのは前の機器です。奥のApacheでHTTP/2が有効かどうかは、外からは分かりません。

自社と委託先で、版とHTTP/2を見る手順

自社のサーバー、委託先のサーバー、レンタルサーバーでは、確認できるところが違います。

1. 自社のサーバーでは、httpd -v（Debian系はapache2 -v）で版を見ます。OSのパッケージで入れた台は、版の数字が範囲に入っていても、修正済みかどうかは配布元の告知で決まります。
2. apachectl -M（Debian系はapache2ctl -M）を実行し、読み込まれているモジュールの一覧にhttp2_moduleとmd_moduleがあるかを確認します。
3. HTTP/2を出しているかの手がかりは、設定のProtocolsの行です。grep -RniE '^\s*Protocols' /etc/httpd /etc/apache2のように探し、h2かh2cがあれば有効です。Debian系では使っていないsites-availableの行も拾うので、sites-enabledの側に出た行を見ます。行が1つもなければ、既定のhttp/1.1だけで動いています。
4. 外から当たりをつけるなら、curl -sI --http2 -o /dev/null -w '%{http_version}\n' https://<サイトのホスト名>/が手軽です。2と出ればHTTP/2で応答していますが、前にCDNがあるサイトでは参考程度にとどめます。
5. 委託先とレンタルサーバーには、Apacheの版、HTTP/2の有効・無効、2.4.71か配布元の修正版を当てる予定日、の3つを文面で聞きます。返事の早さと中身で、どのサイトを先に追いかけるかが決まるはずです。

配布元の修正版は、まだそろっていない

OSのパッケージで入れたApacheは、配布元の修正版を待つしかありません。11月12日朝の時点で、Debianのセキュリティ追跡のページは、Debian 12とDebian 13のapache2をどちらも「vulnerable」と記録していました。修正の版が載っていたのは、開発版（unstable）向けだけです。Ubuntu、Red Hat、SUSEでは、この番号のCVEのページがまだ公開されていません。

では、修正版が届くまでの間はどうするか。

HTTP/2を使う理由が特にないサーバーなら、HTTP/2を止めておけば、この1件の入口はふさがるはずです。サーバーがHTTP/2を出さなければ、ブラウザーはHTTP/1.1でつなぎます。

止め方は2通りあります。Protocolsからh2とh2cを外す方法と、mod_http2を読み込まない設定にする方法です。入口を残さないことを優先するなら、モジュールごと外すほうが確かでしょう。

もっとも、Apacheはこの方法を回避策として示していません。止めた日と戻す条件は、変更の記録に残します。配布元の修正版を当てたら元に戻す、という順番です。

ソースから自分で組んだApacheなら、2.4.71を組み直して入れ替えるだけです。GitHubで配られているmod_h2を別に組み込んでいる場合、対象は2.0.8から2.0.42です。どの方法でも、修正版を当てたら版の表示とパッケージの版をもう一度見て、Apacheを再起動したかまで記録に残してください。

先月の更新をきちんと終えた台ほど、「もう済んだ」と思われがちな時期です。今回はその台にこそ、もう一度手が要ります。