HTTP/2脆弱性CVE-2026-119618(2.4.71)

CVE-2026-119618とは何か

CVE-2026-119618は、Apache HTTP ServerでHTTP/2通信を処理するモジュールmod_http2に存在する重大な脆弱性で、ヒープ破壊とリモートコード実行につながり得ます^[1]。

Apacheはこれを、assign_headers()における「Apache HTTP Serverのmod_http2での、不適切な同期を伴う共有リソースの並行実行の脆弱性」で、「RCEにつながり得る」ものだと説明しています^[1]。ルクセンブルクの国家コンピュータ緊急対応チームであるCIRCLは、HTTP/2ストリームの並行処理中にワーカーが別の実行コンテキスト用に確保されたヘッダーテーブルを変更し得ること、そして共有メモリへのこの安全でないアクセスがヒープを破壊し得ることを説明しています^[2]。

攻撃に成功した者は、ログインせずに、Apacheのウェブサーバープロセスの権限でコードを実行できる可能性があります^[2][4]。BleepingComputerによると、Apache HTTP Serverはおよそ5サイトに1つで稼働していると推定されています^[4]。

上流の修正は、modules/http2/h2_request.cにある1か所の書き込み先を、共有のリクエストヘッダーテーブルから現在のリクエスト自身の入力ヘッダーに変えるものです^[2]。

影響を受けるApacheのバージョンは

影響を受けるのはApache HTTP Server 2.4.55から2.4.70までと、GitHubで配布されている単体のmod_h2 2.0.8から2.0.42までで、バージョン2.4.71で修正されています^[1]。

ディストリビューションのパッケージがあるため、バージョンの確認は複雑になります。CIRCLは、ディストリビューターが保守するパッケージを使う組織に対し、上流のバージョン番号だけに頼らず、セキュリティのバックポートを確認するよう助言しています^[2]。CIRCLがまとめたところでは、Red HatはRHEL 9と10のパッケージについて、メモリアロケーターにより悪用が難しくなるため、重大ではなく重要と評価し、RHEL 8以前は影響を受けないとしています^[2]。

Red Hatは、全般的なCVSS v3.1スコアを9.8(重大)としています^[2][3]。Apache自身の評価も重大です^[1]。

自分のApacheサーバーは脆弱か

影響を受けるビルドを実行し、実際にHTTP/2接続を受け付けている場合に限られます。Red Hatは、HTTP/1.1のみを提供するよう設定されたサーバーは脆弱ではないとしています^[3]。CIRCLは、mod_http2がインストールされているかロードされているだけでは、そのコードパスには到達できないと強調しています^[2]。

• HTTP/2はProtocolsディレクティブで制御されます。「h2」でTLS上、「h2c」で平文上のHTTP/2が有効になります^[2]。
• Apacheのコアの既定値はhttp/1.1で、mod_http2をロードするだけではこれは変わりません^[2]。BleepingComputerは、HTTP/2は既定で無効だと指摘しています^[4]。
• バーチャルホストは独自のProtocolsディレクティブを設定できるため、グローバル設定だけを確認するとHTTP/2が有効なサイトを見逃す場合があります^[2]。
• リバースプロキシ、ロードバランサー、CDNがHTTP/2を終端し、ApacheにはHTTP/1.1だけを転送する場合、クライアントのHTTP/2セッションだけでApacheに到達できるわけではありませんが、各区間でプロトコルを確認する必要があります^[2]。

CIRCLは、バージョンとロード済みモジュール(apachectl -v、apachectl -M)、設定されたバーチャルホスト(apachectl -S)、明示的なProtocols設定のすべてを確認するよう勧めています^[2]。あるエンドポイントがHTTP/2を受け付けるというテスト結果は、そのバックエンドが脆弱だという証明にはならず、否定的なテスト結果も、すべてのポートやバーチャルホストがHTTP/2を拒否している証明にはなりません^[2]。

サーバーがHTTP/2を受け付けるかどうかを確認する方法は

CIRCLは2つの確認を提案しています。サーバー上でApacheの設定を確認し、次にネットワークからネゴシエートされるプロトコルをテストします。テストはプロキシを介さず、Apacheに直接接続して行うのが理想です^[2]。

1. バージョンとモジュールを確認する。apachectl -vでバージョンを確認し、apachectl -Mをhttp2で絞り込んで、モジュールがロードされているかを確認します^[2]。
2. バーチャルホストを一覧する。apachectl -Sは設定済みのすべてのバーチャルホストを表示します。各バーチャルホストが独自のProtocols行を持てるため、これは重要です^[2]。
3. すべてのProtocolsディレクティブを探す。CIRCLは、/etc/apache2と/etc/httpdから、バーチャルホストでの上書きを含む明示的なProtocols設定を検索するgrepコマンドを示しています。パスはディストリビューションによって異なります^[2]。
4. TLS上でテストする。HTTPのバージョンを表示するようにした--http2オプション付きのcurlリクエストで、HTTPSのエンドポイントがHTTP/2をネゴシエートするかが分かります^[2]。
5. 平文でテストする。--http2-prior-knowledge付きのcurlで、通常のHTTPエンドポイントがh2cを受け付けるかを確認します^[2]。

結果は慎重に読み取ってください。HTTP/2と報告される応答は、テストしたエンドポイントがHTTP/2を受け付けたことを示しますが、そのApacheバックエンドが脆弱であることの確認にはなりません。否定的な結果も、すべてのアドレス、ポート、バーチャルホストが拒否している証明にはなりません^[2]。CIRCLの助言は、実効のApache設定とベンダーのパッチ適用済みパッケージの状況を合わせて確認することです^[2]。クラウド環境について、Wizは、侵害されたApacheインスタンスが、近隣のマイクロサービスやクラウドのメタデータエンドポイントへの横展開の足がかりになり得ると警告しており、公開ウェブサイトだけでなくすべてのインスタンスを確認すべき理由の1つになっています^[5]。

CVE-2026-119618を修正する方法は

Apache HTTP Server 2.4.71以降にアップグレードするか、ディストリビューションのパッチ適用済みパッケージをインストールし、Apacheを再起動して、実行中のプロセスが新しいビルドを使っていることを確認します^[2][1]。

1. Apacheを更新する。2.4.71か、CVE-2026-119618に対して明示的にパッチが当てられたベンダーのビルドをインストールします^[2]。
2. 単体のmod_h2を使っている場合は更新する。ベンダーの指示に従ってください。Wizは2.0.42より新しいものに移行するよう述べていますが、CIRCLは確認せずにより新しい単体リリースが存在すると思い込まないよう警告しています^[5][2]。
3. 再起動して確認する。実行中のプロセスが修正済みのビルドを使っていることを確かめます^[2]。
4. まだパッチを当てられない場合はHTTP/2を無効にする。Protocolsをhttp/1.1に設定し、上書きしているすべてのバーチャルホストからh2とh2cを削除し、apachectl -tでテストしてからリロードします^[2]。これはこの脆弱性の経路を塞ぎますが、コードを修正するものではありません^[2]。
5. アクセスを制限する。パッチも、プロトコルの変更もできない場合の一時的な措置として、信頼できるネットワークに制限します^[2]。

BleepingComputerによると、watchTowrの研究者らは、これを「今すぐパッチを当てるか、できるまでh2をやめる」とまとめました^[4]。SecurityWeekによると、Defiantも、問題が基盤となるウェブサーバーに関わるため、WordPressのセキュリティアップデートでは解決できないと警告しています^[3]。

CVE-2026-119618は悪用されているのか

Wizの2026年11月11日の投稿の時点では、利用可能なエクスプロイトはなく、実際の悪用の報告もありませんでした^[5]。ただし、状況は急速に動いています。

• Red Hatは、mod_http2が有効なサーバーに対する確実なエクスプロイトが公開研究で示されたとしていますが、勧告ではその研究を特定していません^[3]。CIRCLは、これだけでは実際の悪用が確認されたことにはならないと指摘しています^[2]。
• GitHub上の公開された概念実証は、メモリ破壊とApacheのクラッシュを再現したと報告していますが、リモートコード実行は示していません^[3]。
• Wizのデータでは、クラウド環境の64%に影響を受けるバージョンを実行するリソースがあり、51%に公開されたインスタンスがあります。Wizは、これは設定を考慮しておらず、必ずしも悪用可能なシステムではないと述べています^[5][3]。

CIRCLは、調査する価値のある兆候として、予期しないワーカーのクラッシュ、異常な再起動、不審な子プロセス、許可されていないファイルの変更、予期しない外向きの接続を挙げています^[2]。これらは手がかりであり、侵害の確定的な指標ではなく、パッチを適用しても、更新前に仕込まれた持続的な足がかりは消えません^[2]。

ApacheのHTTP/2の脆弱性は誰が見つけたのか

Apacheは、2026年10月26日にこの脆弱性を報告したAnthropicのOSS Scannerと、11月3日に独立して報告したGoogle Cloud Vulnerability ResearchのAnthony WeemsおよびSimon Scannellを謝辞に挙げています^[1]。

Anthropicの発見は、内部識別子ANT-2026-MAPKT6MZで記載されています^[1]。SecurityWeekは、この2件の報告を独立した発見と説明しています^[3]。これは、自動化ツールやAI支援ツールが広く使われているオープンソースソフトウェアの重大なバグを見つけた、もう1つの例です。この傾向の意味はAI That Finds Security Bugs: What Glasswing and New CVEs Mean for Youで解説しています。

修正はコミットされ、2.4.71が11月11日に公開されました。これはApacheがoss-securityメーリングリストでこの問題を公表した同じ日です^[1][2]。

Apache 2.4.71は他に何を修正するのか

Apache HTTP Server 2.4.71は、合計3件のCVEを修正します。重大が1件、重要が1件、低が1件です^[1]。

• CVE-2026-106023(重要):リクエスト処理中のmod_mdにおけるNULLポインタ参照で、子プロセスをクラッシュさせ得ます。2.4.30から2.4.70に影響します^[1]。
• CVE-2026-109163(低):mod_vhost_aliasにおける1バイトのスタックバッファ上書きで、Apacheは「CVE-2026-63292の後」と表記しています(この以前の脆弱性は2.4.69で修正されました)。2.4.69と2.4.70に影響します^[1]。

直前のリリースである2026年10月の2.4.69では、20件のCVEが修正されました^[1]。それを飛ばした管理者も、2.4.71に移行すればそれらの修正を受けられます。最近のサーバーの別の脆弱性については、CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Serversを参照してください。

管理者は次に何に注目すべきか

公開されるリモートコード実行のエクスプロイト、お使いのディストリビューション向けのベンダーのバックポート、実際の攻撃の報告に注目してください^[3][5]。

CIRCLは、HTTP/2が有効なインスタンスの棚卸し、各mod_http2ビルドが影響を受けるかの確認、公開システムへの遅滞ないパッチ適用を推奨しています。優先すべきは、インターネットに公開されたウェブサイト、API、共有ホスティング、HTTP/2を転送するフロントエンドの背後にあるApacheサーバーです^[2]。不審な動きを確認した組織は、インシデント対応手順に従い、自国のCSIRTに連絡してください^[2]。