サーバー管理

CVE-2026-119618：ApacheのHTTP/2脆弱性と対処

Apache HTTP Server 2.4.55〜2.4.70のHTTP/2を処理するモジュール（mod_http2）に、認証なしで外部から任意のコードを実行される可能性がある脆弱性、CVE-2026-119618が2026年11月11日に公表されました。影響を受けるのはHTTP/2を有効にしているサーバーで、修正版のパッケージが届くまでは、HTTP/2を止めれば対象から外れます。

CVE-2026-119618の概要

HTTP/2では1本の接続で複数のリクエストを同時に送れるため、mod_http2はそれらを複数のスレッドで並行して処理します。この処理の中で、あるスレッドが別のスレッドの管理するメモリに書き込んでしまう不具合があり、メモリが壊れることで任意のコードを実行される可能性があります（Red Hatの解説）。

  • 深刻度：Apacheの評価はcritical、Red HatのCVSS 3.1のスコアは9.8
  • 影響するバージョン：Apache 2.4.55〜2.4.70（GitHubで配布されているmod_h2は2.0.8〜2.0.42）
  • 修正版：Apache 2.4.71（2026年11月11日公開、Apacheのセキュリティ情報）
  • 攻撃の条件：HTTP/2（h2またはh2c）が有効なこと。HTTP/1.1だけで応答しているサーバーは対象外

11月11日時点では、攻撃コードの公開も実際の悪用も報告されていません（Wizの解説）。一方でRed Hatは、公開された研究によって、mod_http2を有効にした既定設定のサーバーに対して安定して成功する攻撃手法が示されたとしています。

影響を受けるかの確かめ方

まず、HTTP/2が有効かを確かめます。設定ファイルのProtocolsにh2かh2cが書かれていれば有効です。書かれていなければ既定値のhttp/1.1だけになり、mod_http2が読み込まれていてもHTTP/2では応答しません。設定ファイルはRHEL系やAmazon Linuxなら/etc/httpd/、Debian・Ubuntu系なら/etc/apache2/の下にあります。

sudo grep -rn "Protocols" /etc/httpd/

実際の応答は、サーバー上でcurlを実行して確かめます。

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

2と表示されればHTTP/2が有効です。grepでh2・h2cが見つからず、curlで1.1と表示されれば対象外です。--resolveでサーバー自身（127.0.0.1）に接続しているのは、Cloudflareを経由するとCloudflareの応答を見てしまうためです。CloudflareはApacheの設定に関係なく既定でHTTP/2で応答するので、Cloudflare経由のcurlで2と表示されたのを見て、ApacheのHTTP/2が有効だと判断しかけたことがあります。

HTTP/2が有効なら、次にバージョンを確かめます。RHEL系やAmazon Linux 2023では、HTTP/2の処理はhttpdとは別のmod_http2というパッケージが担っていて、バージョン番号もhttpdとは別です。Debian・Ubuntu系ではapache2パッケージに含まれているので、apache2のバージョンを見ます。

rpm -q httpd mod_http2

OSのパッケージは、修正を取り込んでもバージョン番号を2.4.71に上げないことがあります。修正済みかどうかは、次の節の配布元ごとの状況で判断します。

修正版のパッケージに更新する

2026年11月12日時点の配布元ごとの状況です。AlmaLinuxとRocky Linuxは、リポジトリにある最新のmod_http2パッケージの変更履歴で判断しています。RHELの延長サポート版（EUS）は、表とは別の番号で修正されています。

OS 状況
RHEL 9 修正版を公開（mod_http2-2.0.26-7.el9_9.1、RHSA-2026:98981）
RHEL 10 修正版を公開（mod_http2-2.0.29-5.el10_3.1、RHSA-2026:98978）
AlmaLinux 9 修正版を公開（mod_http2-2.0.26-6.el9_8.2.alma.1）
AlmaLinux 10 修正版を公開（mod_http2-2.0.29-4.el10_2.2.alma.1）
Rocky Linux 9・10 未提供
RHEL 8以前 影響なし（該当するコードを含まない）
Amazon Linux 2023・2 修正待ち（Pending Fix）
Debian 12・13 未修正（2.4.71はunstableのみ）
Ubuntu セキュリティ情報に未掲載

dnfを使うOSでは、mod_http2を更新し、rpm -qで表の修正版と同じバージョンになったことを確かめてからApacheを再起動します。読み込まれているモジュールを入れ替えるため、再起動が必要です。

sudo dnf update mod_http2
rpm -q mod_http2
sudo systemctl restart httpd

Debian・Ubuntu系はapache2パッケージで修正されるので、修正版が出たらapache2を更新します。

修正が届くまでHTTP/2を止める

修正版のパッケージがまだ届いていない場合は、Protocolsからh2とh2cを外してHTTP/1.1だけにします。h2cは暗号化しないhttp://の接続でHTTP/2を使う設定で、残しておくとhttp://の接続でHTTP/2を受け付けたままになります。元の行は、修正後に戻すために控えておきます。

# 変更前
Protocols h2 h2c http/1.1
# 変更後
Protocols http/1.1

見落としやすいのは<VirtualHost>の中に書かれたProtocolsです。バーチャルホストのProtocolsはサーバー全体の設定を置き換えるので、全体をhttp/1.1にしても、バーチャルホストにh2が残っていればそのサイトはHTTP/2のままです（Apache 2.4.62で確認）。grepで見つかった行をすべて直してから、設定に誤りが無いかを確認して再起動します。再起動の間、数秒ほど接続できなくなります。

sudo apachectl -t
sudo systemctl restart httpd

Debian・Ubuntu系はサービス名がapache2です。再起動後に「影響を受けるかの確かめ方」のcurlを実行し、1.1と表示されれば止まっています。

HTTP/2を止めても、ブラウザとサーバーは接続の最初に使うプロトコルを取り決めるので、サイトが表示されなくなることはありません。Cloudflare経由のサイトなら、訪問者とCloudflareの間はHTTP/2のままで、HTTP/1.1に変わるのはCloudflareとApacheの間だけです（Cloudflareのドキュメント）。

修正版に更新したら、控えておいたProtocolsの行に戻して再起動し、curlで2と表示されることを確認します。

関連するカスタマイズ

  1. cronのジョブがjournalctl -u crondで表示されない理由と正しい確認方法 cronに登録したジョブが動いているか確認するとき、journalctl -u crondで見るのはやめたほうがいいです。実行ユーザーによってはジョブが1件も表示されず、動いているのに「動いていない」と判断してしまいます […]...
  2. Docker nginxと80番を取り合うcertbot standaloneをwebroot方式に切り替える手順 Dockerのnginxコンテナが80番を使っているサーバーで、ホスト側のcertbotが standalone 方式で登録されていると、更新のたびに Could not bind TCP port 80 で失敗します。...
  3. apt-get updateで「changed its ‘Label’ value」と出る時の対処 apt-get update の最後に「changed its ‘Label’ value」と出るのは、リポジトリのラベル(表示名)が変わったため、aptがそのリポジトリの更新を止めている状態です […]...