Apache HTTP/2の脆弱性 CVE-2026-119618：サーバーの影響確認と2.4.71へのパッチ適用方法

HTTP/2を処理するWebサーバーが、ログインしたことのない第三者に乗っ取られるおそれがあります。これこそがApache HTTP ServerのHTTP/2モジュールに存在する重大な脆弱性「CVE-2026-119618」のリスクであり、すでに修正パッチが提供されています。

本日は2026年11月13日です。Apacheはこのセキュリティホールを塞ぐため、11月11日にバージョン2.4.71をリリースしました。そして今、セキュリティチームは一様に「自分たちの環境は実際に危険に晒されているのか？」という疑問を抱いています。率直に言えば、その答えは単なるバージョン番号だけでは決まりません。HTTP/2が有効化されているか、利用しているLinuxベンダーがすでにパッケージにパッチを適用しているか、そしてトラフィックがどのようにApacheに到達しているかによって左右されます。本ガイドでは、Acme社（仮称）のシステム管理者であるRohitを例にとり、これら3つのポイントを順を追って解説します。

何が起きたのか、わかりやすく解説

HTTP/2 は、Webの主要プロトコルのより新しいバージョンです。その大きな利点は、多数のリクエストとレスポンスが同時に1つの接続を共有できる点にあり、これによりWebサイトが高速化されます。Apacheにおいて、この機能は次のモジュールによって提供されています: mod_http2.

1つの接続を共有するということは、サーバーの複数の部分が同時に動作することを意味し、どのメモリ領域を誰が使用するかについて慎重である必要があります。Red Hatの技術評価によると、今回のケースではその配慮が破綻していました。 worker thread （個々のリクエストを処理するサーバー側の構成要素）は、共有のロックフリーメモリアロケータを介して、 connection thread （接続全体を管理する部分）が所有するメモリ領域への書き込みが可能でした。この問題は、次の関数内に存在します: assign_headers()。2つの部分が調整なしに同一のメモリに書き込みを行うと、内部メモリが破損する可能性があり、メモリの破損は多くの場合、攻撃者のコードを実行するための足がかりとなります。

Red Hatはこの脆弱性に対し、10点満点中9.8のCVSS v3.1スコアを付与しています。このスコアは、攻撃がネットワーク経由で実行可能であり、パスワードが不要で、ユーザーによる操作も一切必要としないことを意味します。

影響を受けるバージョン

Apacheは以下の範囲を影響対象として挙げています:

• Apache HTTP Server 2.4.55から2.4.70まで.
• 個別にリリースされている mod_h2 モジュール（GitHub版）、バージョン 2.0.8から2.0.42まで.

修正版のリリースは、 Apache HTTP Server 2.4.71、またはこの修正を明示的に含むベンダーパッケージです。

Red Hatは自社プラットフォームに関する重要な詳細情報を補足しています:

• RHEL 8以前は影響を受けません。脆弱なコードが含まれていないためです。
• RHEL 9およびRHEL 10 は、「緊急（Critical）」ではなく「重要（Important）」と評価されています。HTTP/2ストリームが個別のメモリアロケータを使用しているため、悪用が大幅に困難になっています。それでもアップデートは必要であり、Red Hatは11月11日に複数のRHEL 9および10ストリーム向けの修正をリリースしました。

攻撃者が実際に掌握できる権限

悪用に成功すると、攻撃者は次の制御権を掌握する可能性があります: Webサーバープロセス。ただし、これは自動的にマシン全体の完全な制御権を意味するわけではありません。攻撃者がアクセスできる範囲は、Apacheプロセスがアクセスできる範囲（アプリケーションのデータ、書き込み権限のあるWebサイトフォルダ、設定ファイル内の認証情報、内部ネットワーク上のデータベースなどのバックエンドサービス）に依存します。

そのため、低特権ユーザーとして実行され、適切に分離されたサーバーでの被害は、Apacheがサーバー内のあらゆる機密情報を読み取れるサーバーよりも小さくなります。この機会に、それらの設定も併せて確認することをお勧めします。

お使いのサーバーは本当に危険に晒されているのか？

こここそが、多くのチームが両方の意味で見誤りやすいポイントです。バージョン番号だけでは危険性の証明にはならず、一見安全そうに見える公開Webサイトであっても安全の証明にはなりません。

モジュールの読み込みだけでは不十分です。 ルクセンブルクのCIRCLは、サービスが実際にHTTP/2を受け入れている場合にのみ脆弱なコードパスに到達可能であると指摘しています。mod_http2がロードされていても、どのリスナーもHTTP/2を提供していなければ、そのパスには到達できません。

どちらの種類のHTTP/2も対象となります。 TLSによる暗号化されたHTTP/2は h2と呼ばれます。TLSを使用しない平文のHTTP/2は h2cと呼ばれます。いずれか一方でもリスナーで有効になっていれば問題となります。

仮想ホストごとに設定が異なる場合があります。 Apacheでは、サーバー全体に加えて個別の仮想ホストごとにもプロトコルを設定できます。メインの設定ファイルだけを確認していると、単独でHTTP/2を有効にしているサイトを見落とす危険があります。

プロキシの存在により状況は変わります。 CDN、ロードバランサー、またはリバースプロキシが前段に配置され、訪問者とはHTTP/2で通信するもののApacheとはHTTP/1.1のみで通信している場合、外部のHTTP/2セッション自体によってこのバグが露呈することはありません。しかし、オリジンサーバーへの直接アクセス、内部リスナー、あるいはHTTP/2をApacheに転送するプロキシが存在する場合は危険に晒されます。

Rohitの置かれた状況は、なぜこれが重要であるかを示しています。Acme社のメインWebサイトはCDNの背後に配置されているため、公開スキャンを実行すると至る所でHTTP/2が検出されます。しかし内部を調査したところ、彼は3つのケースを発見しました。メインサイトのApacheはCDNからHTTP/1.1のみを受信していること、内部Wikiには直接h2でアクセスされていること、そして古いマーケティング用の仮想ホスト1つが独自にh2cを有効化していることです。これら3つのうち2つは早急な対応が必要であり、外部からの公開スキャンではそれらを把握することはできなかったはずです。

ステップ・バイ・ステップ：Rohitが本日実施する作業

ステップ1：すべてのApacheサーバーとそのバージョンを特定する

サーバーの一覧を作成し、各サーバーを確認します。実行するコマンド名はディストリビューションによって異なります。

# RHEL, Rocky, Alma, Fedora
httpd -v
# Debian, Ubuntu
apache2 -v

ベンダーは多くの場合、メインのバージョン番号を変更せずにバグを修正する（これは バックポートと呼ばれます）点に留意してください。バージョン文字列だけでなく、利用しているベンダーのアドバイザリと照合してパッケージを確認してください。

# RHEL family: is the fix for this CVE available or installed?
dnf updateinfo list --cve CVE-2026-119618
# Debian and Ubuntu: does the installed package mention the CVE?
apt changelog apache2 | grep -i CVE-2026-119618

ステップ2：HTTP/2が実際に提供されているか確認する

まずモジュールがロードされているか確認し、次に仮想ホストを含むすべての設定ファイルを検索してプロトコルの設定状況を調べます。

# Is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -i http2
# Where is HTTP/2 enabled? Look for h2 or h2c on any Protocols line
grep -RniE '^\s*Protocols' /etc/httpd/ /etc/apache2/ 2>/dev/null

次に、外部および内部からテストします。 --http2 はTLS経由のh2を要求し、 --http2-prior-knowledge は平文のh2cを試行します。結果が 2 であれば、HTTP/2が使用されたことを意味します。

curl -s -o /dev/null -w '%{http_version}\n' --http2 https://app.example.com/
curl -s -o /dev/null -w '%{http_version}\n' --http2-prior-knowledge http://203.0.113.10/

これらは公開Webサイトだけでなく、オリジンアドレスや内部ホスト名に対しても実行してください。

ステップ3：2.4.71またはベンダー提供の修正版パッケージにパッチを適用する

ベンダーのアップデートを適用し（Apacheをソースからビルドしている場合は2.4.71をビルド）、サービスを再起動して新しいコードが実際に実行されるようにします。パッケージのアップデート後はリロードだけでは不十分な場合があるため、再起動を選択するのが確実で安全です。

# RHEL family
sudo dnf update httpd mod_http2
sudo systemctl restart httpd
# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

その後、ステップ1を再度実行して、稼働中のビルドが修正済みのバージョンであることを確認します。

ステップ4：まだパッチを適用できない場合はHTTP/2を無効化する

一時的な対策として、プロトコルをHTTP/1.1に制限します。メイン設定および独自のプロトコルを設定しているすべての仮想ホストにこれを記述し、 h2 および h2c のエントリをすべて削除します:

Protocols http/1.1

設定の構文を検証して適用し、ステップ2のcurlコマンドで再度テストします。確認すべき結果は 1.1であり、次の値ではありません: 2.

apachectl configtest && sudo systemctl reload httpd    # or apache2

DebianおよびUbuntuでは、 sudo a2dismod http2を実行した後に再起動することで、モジュールを無効化することもできます。パッチ適用によってHTTP/2が復旧するまで、一部の訪問者でページの読み込みがわずかに遅くなることが予想されます。

ステップ5：過去の侵害・不審な兆候を調査する

パッチを適用すれば侵入経路は塞がれますが、それ以前に何者かが侵入したかどうかまではわかりません。CIRCLは、Apacheワーカースレッドの予期せぬクラッシュ、不審な子プロセス、Webフォルダ内の不正なファイル変更、サーバーからの異常な外部宛先接続などを確認することを推奨しています。これら単体で攻撃を決定づけるものではありませんが、いずれも調査に値する重要な兆候です。

エクスプロイトに関する報告について

情報源によって見解が異なるため、見出しの扱いには注意が必要です。Red Hatによると、公開された研究によってmod_http2が有効なデフォルトサーバーに対する確実なエクスプロイトが実証されたとされています。一方、Wizは11月11日時点で利用可能なエクスプロイトは存在せず、実環境での攻撃は確認されていないと報告しました。またCIRCLは、実証（デモ）の存在が直ちに実環境での攻撃を証明するものではないと指摘しています。

またWizは、自社データ内のクラウド環境の64%にこの脆弱性の影響を受けるリソースが含まれていると報告しました。この数字はWiz独自のデータセットに関するものであり、インターネット上のすべてのApacheサーバーにおける割合を示すものではありません。

安全側に立った解釈をすれば、これらの報告において組織的な攻撃キャンペーンは確認されていないものの、実行可能な攻撃手法はすでに実証されているため、迅速にパッチを適用すべきであるということです。

脆弱性の発見者と2.4.71におけるその他の修正点

Apacheは、AnthropicのOSS Scanner、ならびにGoogle Cloud Vulnerability ResearchのAnthony Weems氏およびSimon Scannell氏に謝意を表しています。タイムラインによると、10月26日にAnthropicから、11月3日にGoogleから報告があり、11月11日に修正およびリリースが行われました。

バージョン2.4.71では、これ以外にも2つの小さな問題が修正されています:

• CVE-2026-106023 （重要）：バージョン2.4.30〜2.4.70のmod_mdにおけるNULLポインタ参照解除（子プロセスをクラッシュさせる可能性がある問題）。
• CVE-2026-109163 （低）：バージョン2.4.69および2.4.70のmod_vhost_aliasにおけるスタックバッファ上書き。

まとめ

CVE-2026-119618は極めて深刻です。認証不要、ネットワーク経由で到達可能、そしてWebサーバーを制御されるリスクがあります。しかし、実際の危険度はHTTP/2またはh2cが提供されているか、利用しているベンダーパッケージの状況、そしてトラフィックがどのようにApacheへ到達しているかに依存します。すべてのサーバーを特定し、各仮想ホストを検証し、2.4.71またはベンダーの修正パッチを適用してください。パッチ適用まで待つ必要がある環境ではHTTP/2を無効化し、過去に不正利用の痕跡がないか調査を行ってください。

メリット

• 修正パッチがすでにリリースされており、安全を確保するための明確な手順が存在する。
• 応急処置として、設定ファイルの1行を変更するだけでHTTP/2を無効化できる。
• RHEL 8以前は影響を受けず、RHEL 9および10では悪用がより困難である。
• Apacheに対してHTTP/1.1のみで通信するプロキシを使用していれば、露出リスクを低減できる。
• 今回の見直しは、Apacheプロセスがアクセス可能なリソースを制限・強化する絶好の機会となる。

デメリット

• 認証不要で悪用可能であり、スコアも9.8と高いため、露出しているサーバーは現実的な脅威に晒される。
• ベンダーが修正をバックポートするため、バージョン文字列だけでは誤認しやすい。
• 仮想ホストごとの個別設定により、危険に晒されているサイトを1つ見落とす恐れがある。
• HTTP/2を無効化すると、一部のページで読み込み速度がわずかに低下する可能性がある。
• パッチを適用しても、修正前にサーバーが攻撃を受けていたかどうかは判明しない。

注意事項

本記事は情報提供・教育を目的としたものです。ホスト名、IPアドレス、会社名「Acme」はプレースホルダーであり、ご自身の環境の値に置き換える必要があります。コマンドはディストリビューションやバージョンによって異なるため、ベンダーのアドバイザリを確認し、まずは非本番環境のサーバーで変更をテストしてください。エクスプロイトや影響範囲に関する記述は、ここに要約されたベンダーや研究者の発表に基づいており、変更される可能性があるため、それらに依拠する前にApacheやベンダーの公式アドバイザリをご確認ください。

よくある質問（FAQ）

• CVE-2026-119618とは何ですか？ — Apache HTTP ServerのHTTP/2モジュールに存在するメモリ破損の重大な脆弱性であり、認証なしでリモートコード実行が行われる可能性があります。
• 影響を受けるApacheのバージョンはどれですか？ — Apache HTTP Server 2.4.55から2.4.70まで、および個別に提供されているmod_h2モジュールのバージョン2.0.8から2.0.42までです。
• どのバージョンで修正されますか？ — 2026年11月11日にリリースされたApache HTTP Server 2.4.71、またはこの修正を明示的に含むベンダーパッケージです。
• mod_http2がロードされていてもHTTP/2が有効化されていない場合、サーバーは安全ですか？ — 脆弱なコードパスはサービスがHTTP/2を受け入れる必要があるため、いずれのリスナーでもh2およびh2cを提供していないサーバーは、この脆弱性による攻撃を受けることはありません。
• CDNやロードバランサーの背後にいれば安全ですか？ — プロキシがApacheとHTTP/1.1で通信しており、かつ誰もオリジンサーバーにHTTP/2で直接アクセスできない場合にのみ安全です。
• RHELは影響を受けますか？ — RHEL 8以前は影響を受けません。RHEL 9および10は「重要（Important）」と評価されており、Red Hat提供のアップデートを適用する必要があります。
• Apacheで一時的にHTTP/2を無効化するにはどうすればよいですか？ — メイン設定およびすべての仮想ホストに Protocols http/1.1 を設定し、設定テストを実行してからApacheをリロードします。
• この脆弱性は実環境で悪用されていますか？ — ここで引用した報告では公開デモが示されているものの、実環境での攻撃は確認されていません。組織的な攻撃キャンペーンを過信せず、迅速にパッチを適用してください。

タグ

#apache #cybersecurity #cve2026119618 #http2 #modhttp2 #vulnerabilitymanagement #patchmanagement #linuxsecurity #webserver #devsecops