はじめに
2026年11月11日、Apache HTTP Server Project は Apache HTTP Server 2.4.71 を公開し、HTTP/2 を処理する mod_http2 の脆弱性 CVE-2026-119618 を修正しました。Apache はこの脆弱性を Critical と評価しており、リモートコード実行（RCE）につながる可能性があるとしています。
一方、実務では「バージョンが対象範囲に入っているか」だけでは判断できません。mod_http2 がロードされていても HTTP/2 を受け付けていない構成があり、OS 標準パッケージではバージョン番号を変えずに修正がバックポートされる場合もあります。本記事では、公式情報をもとに影響確認の順序と更新判断を整理します。
- CVE-2026-119618 の概要、影響バージョン、RCE リスクの捉え方
- mod_http2 のロード、Protocols 設定、実際の HTTP/2 通信を切り分ける手順
- OS 標準パッケージのバックポートを考慮した修正済み判定の方法
- 2.4.71 への更新手順と、更新できない場合の暫定的な緩和策
結論として、Apache HTTP Server 2.4.55〜2.4.70 で HTTP/2（h2 または h2c）を有効にしているサーバーは、2.4.71 または配布元が CVE-2026-119618 の修正を明示したパッケージへの更新を優先してください。OS 標準パッケージを利用している場合は、上流のバージョン番号ではなく、ベンダーの CVE 情報とパッケージの変更履歴で修正の有無を判定します。
CVE-2026-119618 の概要と RCE リスク
CVE-2026-119618 は、mod_http2 の assign_headers() における並行処理上の問題です。CWE-362（共有リソースの不適切な同期による並行実行）に分類され、Apache はヒープ破損と RCE の可能性を示しています。
参考: Apache HTTP Server 2.4 vulnerabilities
“vulnerability in Apache HTTP Server’s mod_http2 in assign_headers() can lead to RCE.”
（Apache HTTP Server の mod_http2 の assign_headers() に存在する脆弱性は、RCE につながる可能性があります。）
https://httpd.apache.org/security/vulnerabilities_24.html
公開されている基本情報
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-119618 |
| Apache の深刻度 | Critical |
| 対象モジュール | mod_http2（assign_headers()） |
| 脆弱性の種類 | CWE-362（並行処理における同期不備） |
| 影響 | ヒープ破損、RCE の可能性 |
| 報告日 | 2026年10月26日 |
| 公開日 / 修正版リリース日 | 2026年11月11日 |
| 上流の修正版 | Apache HTTP Server 2.4.71 |
Apache の脆弱性一覧によると、2.4.71 では CVE-2026-119618 のほかに、mod_md の NULL ポインター参照（CVE-2026-106023、Important）を含む計 3 件の脆弱性が修正されています。mod_http2 を使っていない環境でも、2.4.71 への更新を検討する理由になります。
RCE リスクと悪用状況の捉え方
Red Hat は CVE ページで、HTTP/2 は 1 本の接続で複数のリクエストを同時に扱い、mod_http2 はそれらを複数スレッドで処理すると説明しています。そのうえで、スレッド安全性の不備により、あるスレッドが別のスレッドのメモリを変更し得ることを原因として挙げています。
上の図は概念を示すものであり、ヒープ破損から RCE に至る具体的な経路は Apache の公表情報では示されていません。悪用状況について、執筆時点で確認できた情報は次のとおりです。
- Red Hat は深刻度を Critical とし、mod_http2 を有効にした標準構成のサーバーに対して、公開された研究で信頼性の高いエクスプロイトが実証されたと説明しています。
- 同じく Red Hat は、RHEL 9 と RHEL 10 の mod_http2 は HTTP/2 ストリームごとに別のアロケーターを使うため、悪用の難易度が大幅に上がるとしています。
- 執筆時点で確認した範囲では、実環境での悪用（in the wild）の報告や CISA KEV への登録は確認できていません。
実環境での悪用が確認されていないことは、悪用されないことを意味しません。また、すべての構成で同じ条件・同じ難易度で RCE が成立するとは限らないため、次章以降の手順で自社環境の条件を確認してください。
影響バージョンと mod_http2 の利用条件
影響を受けるのは、Apache HTTP Server 2.4.55〜2.4.70 と、GitHub で配布される mod_h2 2.0.8〜2.0.42 です。ただし、対象バージョンであることに加えて、HTTP/2 を受け付ける設定かどうかが判断の分かれ目になります。
| コンポーネント | 影響を受けるバージョン | 修正版 |
|---|---|---|
| Apache HTTP Server（上流） | 2.4.55〜2.4.70 | 2.4.71 |
| mod_h2（GitHub 版） | 2.0.8〜2.0.42 | Apache の公表情報では修正版の番号は明示されていない |
| OS 標準パッケージ | ベンダーの CVE 情報で判定 | ベンダーの Security Advisory で判定 |
HTTP/1.1 のみのサーバーは影響を受けない
Red Hat は、Protocols ディレクティブで h2 または h2c を有効にしたサーバーが影響を受け、HTTP/1.1 のみを提供するサーバーは影響を受けないと説明しています。
参考: Red Hat Customer Portal（CVE-2026-119618）
“servers serving only HTTP/1.1 are not affected.”
（HTTP/1.1 のみを提供するサーバーは影響を受けません。）
https://access.redhat.com/security/cve/cve-2026-119618
Apache の mod_http2 ドキュメントも、Protocols で h2 または h2c が有効になっていないサーバーや VirtualHost では、接続を HTTP/2 のプリアンブルとして検査しないと説明しています。http2_module がロードされていることと、HTTP/2 を受け付けていることは別の状態です。
Protocols 設定の違い
Apache の HTTP/2 ガイドと mod_http2 ドキュメントに基づくと、代表的な設定の違いは次のとおりです。h2 は TLS の ALPN でネゴシエーションする HTTP/2、h2c は TLS を使わない平文の HTTP/2 です。
| 設定 | 受け付けるプロトコル | CVE-2026-119618 の観点 |
|---|---|---|
Protocols h2 http/1.1 | TLS 接続で HTTP/2（h2）を優先し、非対応クライアントは HTTP/1.1 | HTTP/2 が有効なため確認・更新対象 |
Protocols h2 h2c http/1.1 | h2 に加え、平文の HTTP/2（Upgrade または Direct モード）も受け付ける | HTTP/2 が有効なため確認・更新対象。平文ポートも経路になる |
Protocols http/1.1 | HTTP/1.1 のみ | Red Hat の説明では影響を受けない構成 |
注意したいのは設定の場所です。Apache の HTTP/2 ガイドでは、サーバー全体を Protocols http/1.1 とし、特定の VirtualHost の中だけで Protocols h2 http/1.1 を指定する例を示しています。この場合、HTTP/2 を提供するのはその VirtualHost への TLS 接続だけです。逆に、サーバー全体で h2 を有効にし、一部の VirtualHost だけ HTTP/1.1 に制限している構成もあり得ます。サーバー全体の設定と、すべての VirtualHost の Protocols を個別に確認してください。
Debian の apache2 パッケージでは、mods-available/http2.conf に Protocols h2 h2c http/1.1 が記載されています。a2enmod http2 でモジュールを有効にすると、この設定も読み込まれる点に注意してください。
CVE-2026-119618 の影響確認手順
影響確認は、バージョン → モジュール → 設定 → 実通信 → 修正状況の順に進めます。前の段階で影響がないと判断できれば、以降は確認範囲を絞れます。
Apache のバージョンと mod_http2 のロード状態
実行ファイル名は配布環境によって異なります。RHEL 系やソースビルドでは httpd、Debian / Ubuntu 系では apache2ctl を経由するのが一般的です。Debian の apache2.conf には、標準設定では /usr/bin/apache2 を直接呼び出しても動作せず、apache2ctl などを使う旨が記載されています。以下は RHEL 系の例で、Debian / Ubuntu 系では httpd を apache2ctl に読み替えてください。
-v はバージョンを表示します。-V はビルドパラメーターも表示するため、設定ファイルの場所を特定する手がかりになります。
httpd -v
httpd -V表示されるのは上流のバージョンです。OS 標準パッケージの場合、2.4.71 より古い番号でも修正済みの可能性があるため、この時点で脆弱と断定しません（後述のバックポート確認を参照）。
-M は、ロードされている静的モジュールと共有モジュールの一覧を表示します。
httpd -M | grep -i http2http2_module が表示されなければ、mod_http2 による HTTP/2 処理は行われていません。表示された場合は、次の Protocols 設定の確認へ進みます。なお、mod_proxy_http2（proxy_http2_module）は Apache からバックエンドへ HTTP/2 で接続するための別モジュールです。
-S で VirtualHost の構成を表示し、どの設定ファイルにどの VirtualHost が定義されているかを把握します。そのうえで、手順 1 で特定した設定ディレクトリー配下を検索し、サーバー全体と各 VirtualHost の Protocols を確認します。
httpd -S
grep -Rni "Protocols" [設定ディレクトリー]Include されている設定ファイルや、コメントアウトされた行も検索結果に含まれます。実際に読み込まれている行かどうかを確認してください。
コマンドオプションの詳細は、Apache 公式の httpd コマンドリファレンス、Protocols の仕様は core モジュールのドキュメントを参照してください。
実際の HTTP/2 通信を curl で確認する
設定の確認に加えて、実際に HTTP/2 でネゴシエーションされるかを curl で確認します。まず、curl 自体が HTTP/2 に対応しているかを curl -V の Features 行に HTTP2 があるかで確認します。
次に、--write-out（-w）の http_version 変数で、実際に使われた HTTP バージョンを表示します。
curl --http2 -sS -o /dev/null -w 'HTTP/%{http_version} %{response_code}\n' https://www.example.com/結果は次の 3 段階に分けて解釈します。
- HTTP/2 を要求した
-
--http2を付けた状態です。curl のマニュアルによると、HTTPS では TLS ハンドシェイクで HTTP/2 をネゴシエーションし、成立しなければ HTTP/1.1 にフォールバックします。要求しただけでは HTTP/2 の利用を意味しません。 - HTTP/2 で通信できた
-
http_versionが2と表示された状態です。クライアントから見た接続先が HTTP/2 を受け付けたことを示します。 - Apache が HTTP/2 を処理している
-
接続先が Apache 自体であり、その Apache が HTTP/2 を処理している状態です。前段にロードバランサー、CDN、リバースプロキシがあると、HTTP/2 を終端しているのは前段の機器である可能性があります。
前段の機器がある場合は、Apache が待ち受けるアドレスへ直接接続して確認します。名前解決を固定する --resolve を使うと、SNI と Host ヘッダーを維持したまま接続先だけを切り替えられます。
curl --http2 -sS -o /dev/null -w 'HTTP/%{http_version} %{response_code}\n' --resolve www.example.com:443:[Apache サーバーの IP アドレス] https://www.example.com/h2c を有効にしている場合は、平文ポートも確認対象です。--http2-prior-knowledge は、Upgrade を使わずに平文で HTTP/2 を直接送信するオプションです。
curl --http2-prior-knowledge -sS -o /dev/null -w 'HTTP/%{http_version} %{response_code}\n' http://www.example.com/なお、curl の確認は特定の VirtualHost とポートに対する結果です。設定上 HTTP/2 が有効でも、確認した経路では HTTP/2 が使われないこともあるため、影響判断の最終的な根拠は Protocols 設定とし、curl は設定どおりに動作しているかの確認に使うことを推奨します。オプションの詳細は curl のマニュアルを参照してください。
OS パッケージとバックポートの確認
RHEL、Debian、Ubuntu などの 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
判定では、次の 4 つを区別します。
| 確認対象 | 確認できること | 確認方法の例 |
|---|---|---|
| 上流のバージョン | Apache の公表した影響範囲との照合 | httpd -v |
| パッケージのバージョンとリリース番号 | 導入済みパッケージの特定 | RHEL 系: rpm -q httpd mod_http2Debian / Ubuntu 系: dpkg -l 'apache2*' |
| ベンダーの CVE 情報 / Security Advisory | どのパッケージで修正されたか | 各ベンダーの CVE ページ、RHSA、DSA、USN |
| パッケージの変更履歴 | 導入済みパッケージに修正が含まれるか | RHEL 系: rpm -q --changelog mod_http2Debian / Ubuntu 系: apt changelog apache2 |
RHEL 系では、mod_http2 が httpd 本体とは別のパッケージとして提供されています。Red Hat が今回公開したセキュリティ更新も mod_http2 パッケージが対象とされているため、RHEL 系では httpd だけでなく mod_http2 パッケージの修正状況を確認してください。変更履歴に CVE 番号が記載されていれば、修正を取り込んだパッケージと判断する材料になります。
執筆時点で確認できた主なベンダーの状況は次のとおりです。具体的な修正版パッケージ番号は、各ベンダーの一次情報で確認してください。
| ベンダー | 確認できた状況（執筆時点） | 確認先 |
|---|---|---|
| Red Hat | CVE ページで深刻度を Critical と評価。mod_http2 のセキュリティ更新が公開されている | Red Hat CVE ページ |
| Debian | 第三者の 11月11日時点の確認では、unstable が修正済み、安定版系列は未修正と表示されていた | Debian Security Tracker |
| Ubuntu | 執筆時点では CVE ページを確認できず | Ubuntu Security の CVE ページ |
コンテナイメージやアプライアンス製品に組み込まれた Apache は、OS パッケージとは別に提供元の情報を確認する必要があります。脆弱性スキャナーの結果が上流のバージョン番号だけで判定している場合は、バックポート済みでも検出されることがあるため、上記の方法で裏付けを取ってください。
Apache 2.4.71 への更新と暫定的な緩和策
恒久対策は、Apache HTTP Server 2.4.71、または配布元が CVE-2026-119618 の修正を明示したパッケージへの更新です。確認した範囲では、Apache は回避策を公表していません。
修正版への更新手順
前章の確認結果から、OS 標準パッケージ、ソースビルド、コンテナイメージ、製品組み込みのどれに当たるかを確定します。OS 標準パッケージはベンダーの修正済みパッケージ、ソースビルドは上流の 2.4.71 が更新先です。
設定ディレクトリー一式、TLS 証明書と秘密鍵、独自に追加したモジュール、起動スクリプトや systemd のユニット設定を退避します。ソースビルドの場合は、現行バイナリーとビルドオプション（httpd -V の出力）も保存しておくと切り戻しに使えます。
本番と同じ設定でステージング環境を更新し、HTTP/2 と HTTP/1.1 の両方、TLS、各 VirtualHost、リバースプロキシ連携（mod_proxy 経由のバックエンド接続）が従来どおり動作するかを確認します。
パッケージまたはバイナリーを更新したら、更新後のモジュールを読み込ませるために Apache を再起動します。冗長構成の場合は、ロードバランサーから 1 台ずつ切り離して更新すると、サービス断を抑えられます。
更新できない場合の HTTP/2 無効化
すぐに更新できない場合は、修正版を適用するまでの暫定策として HTTP/2 の無効化を検討します。Red Hat が HTTP/1.1 のみを提供するサーバーは影響を受けないとしているため、サーバー全体とすべての VirtualHost で Protocols を HTTP/1.1 のみに変更します。
Protocols http/1.1Protocols は VirtualHost ごとに指定できるため、サーバー全体だけを変更しても、VirtualHost 側に h2 や h2c の指定が残っていれば HTTP/2 は無効になりません。Debian / Ubuntu 系では、a2dismod http2 で mod_http2 自体を無効にする方法もあります。変更後は構文を確認してから再起動し、前章の curl で http_version が 1.1 になることを、h2 と h2c の両方の経路で確認してください。
HTTP/2 の無効化には、次の制約があります。
- CVE-2026-119618 の修正ではなく、HTTP/2 経由の攻撃経路を閉じる暫定策です。修正版の適用を置き換えるものではありません。
- 2.4.71 で修正された他の 2 件の脆弱性には効果がありません。
- gRPC など HTTP/2 を前提とするクライアントや API、前段のプロキシから h2c で接続している構成は通信できなくなる可能性があります。
- ブラウザーは HTTP/1.1 にフォールバックしますが、多数のリソースを読み込むページでは表示性能が変わる可能性があります。
前段のロードバランサーや CDN で HTTP/2 を終端し、Apache へは HTTP/1.1 で転送している構成もあります。その場合でも、Apache 自体の Protocols 設定で HTTP/2 が有効なら、前段を経由しない経路から攻撃を受ける可能性があるため、Apache 側の設定と到達経路を確認してください。
更新後の動作確認と注意点
更新後は、修正が適用されたことと、サービスが正常に動作していることの両方を確認します。
ソースビルドは httpd -v で 2.4.71 になったことを確認します。OS 標準パッケージは、パッケージのバージョンがベンダーの Security Advisory に記載された修正版以上であることと、変更履歴に CVE-2026-119618 が含まれることを確認します。
-t は設定ファイルの構文チェックを行い、問題がなければ Syntax OK を返します。あわせて、httpd -M で必要なモジュールが読み込まれていることを確認します。
httpd -t主要な VirtualHost に curl でアクセスし、HTTP/2 と HTTP/1.1（--http1.1）の両方でステータスコードと http_version が想定どおりであることを確認します。リバースプロキシ先のアプリケーションへの到達も確認します。
更新前後でエラーログに新しいエラーや子プロセスの異常終了が出ていないか、アクセスログで 5xx の増加がないかを確認します。
問題が発生した場合の切り戻しは、更新前のパッケージやバイナリーに戻すと脆弱な状態に戻ることを前提に判断します。切り戻す場合は、修正版を再適用できるまでの間、前章の HTTP/2 無効化をあわせて適用することを推奨します。
mod_http2 では、2026年に入ってから CVE-2026-23918（2.4.67 で修正）、CVE-2026-49975（2.4.68 で修正）、CVE-2026-57941（2.4.69 で修正）など、修正が続いています。HTTP/2 を利用している場合は、Apache の脆弱性一覧と OS ベンダーの Security Advisory を定期的に確認する運用を推奨します。
まとめ
CVE-2026-119618 は、mod_http2 の並行処理の不備により RCE につながる可能性がある Critical の脆弱性です。影響判断の鍵は、バージョン番号ではなく HTTP/2 の有効化状況とベンダーの修正状況にあります。HTTP/2 を有効にしている場合は、修正版への更新を優先してください。
- 影響範囲は Apache HTTP Server 2.4.55〜2.4.70 で、修正版は 2.4.71
- Red Hat の説明では HTTP/1.1 のみのサーバーは影響を受けない
- http2_module のロードと HTTP/2 の受け付けは別の状態です。
- Protocols はサーバー全体とすべての VirtualHost で確認します。
- OS 標準パッケージは CVE 情報と変更履歴で修正を判定します。
- HTTP/2 の無効化は修正版を適用するまでの暫定策にとどめます。
以上、最後までお読みいただきありがとうございました。
