Apache HTTP ServerのHTTP/2に認証不要RCE｜2.4.71更新と構成別の確認

Apache HTTP ServerのHTTP/2処理に、認証なしでリモートコード実行につながる重大な脆弱性CVE-2026-119618が公表されました。Apacheは2026年11月11日に2.4.71を公開しています。対象は上流版2.4.55〜2.4.70のmod_http2を使う構成です。WebサイトやAPIをApacheで受け付けている運用担当者は、HTTP/2の有効化とパッケージ提供元を確認し、修正版の適用を優先してください。

今回の判断では、Apache本体の版だけでなく、読み込むモジュールと接続経路を合わせて調べる必要があります。CDNやロードバランサーの画面にHTTP/2と表示されても、Apacheまで同じプロトコルが届くとは限りません。逆に、普段の公開URLがHTTP/1.1でも、別のVirtualHostや直接到達できるオリジンでHTTP/2を受け付けている場合があります。

何が修正され誰に影響するか

Apacheの公式セキュリティ告知は、mod_http2のassign_headers()で共有資源を扱う際の同期不備により、ヒープ破損とコード実行が生じ得ると説明しています。Apacheの評価はcriticalです。別配布のmod_h2についても2.0.8〜2.0.42が影響範囲として記載されています。本体とモジュールを別々に更新する構成では、両方の出所を確認します。

Red HatのCVE説明は、HTTP/2を有効にしたサーバーが対象で、HTTP/1.1だけの構成はこの脆弱性の影響を受けないとしています。認証不要のコード実行と公開研究による実証にも言及していますが、これは実環境での悪用確認とは別です。本稿で確認した一次資料から、実攻撃の有無を断定しません。

OSの製品差も重要です。Red HatはRHEL 9・10の実装では攻撃の複雑さが増し、製品別評価がImportantになると説明し、RHEL 8以前は影響なしとしています。この判定を他のOSや独自ビルドへそのまま転用してはいけません。上流の版番号と配布元の影響判定を分け、自分が導入したパッケージに対応する勧告を使います。

同じリリースで修正された別の二件

2.4.71には主題のRCE以外の修正も含まれます。Apacheの2.4.71変更履歴では、mod_mdのNULLポインター参照による子プロセスのクラッシュと、mod_vhost_aliasのスタック上の1バイト書き込み超過を確認できます。HTTP/2を使わないサーバーでも、これらのモジュールを使っていれば別途更新判断が必要です。

CVE	対象モジュール	上流の影響範囲	Apache評価
CVE-2026-119618	mod_http2	2.4.55〜2.4.70	critical
CVE-2026-106023	mod_md	2.4.30〜2.4.70	important
CVE-2026-109163	mod_vhost_alias	2.4.69〜2.4.70	low

この表はApache上流の範囲であり、OS提供パッケージの修正済みビルド番号を示したものではありません。また、三件をまとめて「すべて認証不要RCE」と解釈しないでください。影響の内容と対象モジュールは異なります。今回はCVE-2026-119618を優先対象にしつつ、同じ保守作業で他の二件も取りこぼさない構成確認が必要です。

まず稼働中のApacheとモジュールを特定する

以下は本サイトが提案する確認順です。サーバーへ変更を加える前に、サービスの起動設定、実行ファイルの場所、読み込む設定ファイルを確認します。複数版が同居していると、シェルで見つかるhttpdと本番サービスが使うhttpdが違う場合があります。コンテナではホスト側だけでなく、実際のコンテナ内で確認してください。

httpd -v
httpd -V
httpd -M
httpd -S
httpd -t

Apacheのhttpdコマンド資料によると、-vは版、-Vはビルド情報、-Mは静的・共有の読み込みモジュール、-SはVirtualHost設定、-tは設定の構文検査を表示します。OSによって実行名はapache2などになり、起動用ラッパーも異なります。サービスと同じ設定を対象にする必要があり、別の設定でSyntax OKが出ても本番設定の検証にはなりません。

-Mの結果ではhttp2_moduleの有無を確認し、md_moduleとvhost_alias_moduleも記録します。ただし、http2_moduleが表示されるだけでは、対象VirtualHostがHTTP/2を許可しているとまでは言えません。モジュールの読み込みとプロトコル設定は別の条件です。モジュール一覧、設定、実際の到達経路の三つを対応付けることが調査の中心になります。

ProtocolsはVirtualHostごとに確認する

mod_http2の公式資料は、HTTP/2を使うにはProtocolsで有効化する必要があると説明しています。h2はTLS上のHTTP/2、h2cは暗号化しないTCP上のHTTP/2です。ブラウザーでHTTPSを確認するだけでは、内部向けのh2cや別ポートの設定を見落とすおそれがあります。

Protocols h2 http/1.1
# h2cも許可する構成例
Protocols h2 h2c http/1.1

これは既存設定を読み取るための例であり、新たにHTTP/2を有効にする指示ではありません。ApacheのHTTP/2ガイドでは、Protocolsをサーバー全体にもVirtualHost内にも置けることが示されています。全体がHTTP/1.1でも個別ホストがh2を許可している構成があるため、メイン設定一か所だけで判定せず、Include先と個別ホストを追います。

接続経路は「利用者→CDN・ロードバランサー」と「その先→Apache」を分けて整理します。前段がHTTP/2を終端してApacheへHTTP/1.1で接続するなら、その通信経路はApacheのHTTP/2処理とは異なります。ただし、前段を通らず到達できるIP、保守用ポート、別ドメインも確認対象です。前段の設定変更だけで全オリジンの対処が済んだとは判断しません。

更新を待つ間にHTTP/2を止める場合の条件

恒久対応は修正版の適用です。Apacheの2.4.71リリース発表は、旧版利用者へ更新を勧めています。すぐに更新できない場合、HTTP/2を受け付けない状態へ限定することは、影響条件を外すための暫定案になります。ただし、Apacheの個別告知に掲載された回避策としてではなく、HTTP/2が必要という条件に基づく運用上の提案として扱います。

暫定変更を選ぶなら、対象VirtualHostでProtocolsをHTTP/1.1だけへ限定し、h2とh2cの両方が残らないように確認します。設定の継承や個別上書きを見落とさず、Protocolsディレクティブの適用範囲と照合します。TLSや証明書検証を無効にする必要はありません。暗号化を弱める変更と、HTTP/2の受付を止める変更を混同しないでください。

変更前には、HTTP/2を前提とするクライアント、監視、API、内部通信への影響を検証します。構文検査に成功しても、利用者が必要な通信を続けられる保証にはなりません。反映後は各対象ホストの接続結果を確認し、監視のエラー率や遅延も比較します。HTTP/2を停止できた場合も、他の二件や将来の問題に備えるため更新計画は維持します。

提供元の修正を適用し稼働実体まで確認する

上流ソースから導入した環境では2.4.71以降を更新先にし、外部モジュールと依存ライブラリの互換性を検証します。OS提供パッケージでは、提供元がCVE-2026-119618へ対応したビルドと勧告を確認します。古い上流番号へ修正が取り込まれる場合があるため、表示が2.4.71未満という理由だけで未修正と断定せず、パッケージのリリース番号と提供元の説明を残します。

コンテナやサーバーイメージでは、修正版を含む成果物を再作成して配備します。検証機だけを更新しても、スケールアウトや再起動時に旧イメージから増えるなら再び未修正の実体が現れます。起動テンプレート、デプロイ設定、復旧用イメージも同じ更新対象へ入れ、稼働する各インスタンスの成果物識別子と対応付けてください。

反映後は、サービスの再起動・再展開手順に従い、新しいプロセスで版とモジュールを確認します。単にパッケージ管理の処理が成功したことと、実際に新しいコードで通信を処理していることは分けて確認します。複数台構成では少数系でログイン、フォーム、API、静的ファイルを試してから広げ、最後に全対象台数と更新結果を照合します。

対応完了と侵害調査を分けて記録する

今回確認した公式資料には、侵害を一意に判定するログ文字列やIOCは示されていません。そのため、通常ログに特定の痕跡がないことをもって未侵害と判定したり、独自の攻撃リクエストを本番へ送って安全性を試したりしないでください。異常な子プロセス、クラッシュ、不審な変更があれば、更新作業とは別に証拠保全と調査へ引き継ぐ判断が必要です。

• 対象ごとにパッケージ提供元・版・モジュール・Protocols・到達経路を記録する
• 修正済みビルドと再起動・再展開後の実体を結び付ける
• 暫定停止を残した場合は解除条件と担当者を決める
• 既知の侵害がないという判断と、脆弱なコードを更新したという事実を区別する

本稿は11月12日に確認した一次資料を基にした脆弱性ニュースと対応手順です。手順例は実環境での実測報告ではありません。優先するのは、HTTP/2を受け付ける未修正Apacheを特定し、提供元の修正版を稼働系まで適用することです。JVNの今回の更新情報も参照し、製品別の続報が出た場合は資産台帳と照合して対応を見直してください。

関連記事

• 緊急パッチを安全に適用する実務ランブック｜資産確認からロールバックまで — 少数系からの反映、復旧点、稼働実体の検証を運用手順へ落とし込む際の補足です。