HTTPd（CVE-2026-119618）：Apache HTTP Server mod_http2におけるヒープ破壊とRCEの検出

購読する

タイムライン

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

この脆弱性は、Apache HTTP ServerのHTTP/2モジュールであるmod_http2に存在します。同じモジュールはGitHub上のmod_h2としても単独で公開されており、こちらも影響を受けます。

Apacheのアドバイザリは、この脆弱性を重大（Critical）と評価しています。ただし、ApacheがCVE採番機関（CNA）として管理するCVEレコードには、CVSSスコアが付いていません。一方、Red HatとAmazonはいずれも重大と評価し、CVSS v3.1で9.8としています。CISAは、CVSS v3.1で8.1の高（High）に分類しています。

Red Hatは、自社のRHEL 9および10向けビルドについては、Criticalではなく「Important」と評価しています。これらのビルドは各HTTP/2ストリームを「別個のアロケーターから割り当てており、脆弱性を悪用する難易度が大幅に高まる」ためです。 

この脆弱性の深刻度や、自組織の環境での優先度は、まずHTTP/2が有効かどうかによって決まります。

バージョン番号だけでは影響の有無を確認できません。次の点も確認してください。

• ディストリビューションのパッケージ：ベンダーは、アップストリームのバージョンを変えずに修正をバックポートすることがよくあります。httpd -vやapache2 -vだけでなく、ベンダーのアドバイザリも確認してください。
  • 11月13日時点で、Debian 12および13（2.4.71-1~deb12u1、2.4.71-1~deb13u1）、Ubuntu 22.04から26.10、Alpine、Fedora、Amazon Linux 2および2023、WolfiとChainguardでは修正版が公開されています。 
  • SUSE、openSUSE、Photon OS、およびRHEL系の複数のリビルド版は、ベンダーの修正を待っている状態でした。
• 下流の製品：httpdを再パッケージしているベンダーの製品（Red Hat JBoss Core Services（jbcs-httpd24-mod_http2）やRed Hat Hardened Imagesなど）は、バージョン番号だけで影響ありと記載される場合があります。実際に影響を受けるかどうかは、その製品が何を同梱しているかによります。mod_http2が実際に存在し、ロードされているかを確認してください。例えば、SysdigがRed Hat Hardened Imagesのhttpdイメージをスキャンしたところ、影響ありと表示されましたが、このイメージにはmod_http2が含まれていません。そのため、リスクは受容できます。修正状況はベンダーのアドバイザリで確認してください。
• 最近のアップグレード：5月のHTTP/2の脆弱性CVE-2026-23918に対応して2.4.67にアップグレードしたサーバーも、このCVEの影響範囲に含まれたままです。

HTTPdのRCE脆弱性の仕組み

HTTP/2は、1つの接続上で多数のリクエストを並列ストリームとして運びます。この脆弱性は、その並行処理に起因します。

Apacheのアドバイザリは、この不具合をassign_headers()における「不適切な同期による共有リソースの並行実行（Concurrent Execution using Shared Resource with Improper Synchronization）」と説明しており、CVEレコードにはCWE-362が記載されています。一方、Red HatはCWE-20としています。Red Hatは根本原因を「ワーカースレッドが、ロックを持たない共有アロケーターを通じて、接続スレッドが所有するメモリに書き込むこと」と説明しています。実際には、2つのスレッドが同じヒープを破壊し得ます。

修正はassign_headers()内の1行の変更です。修正前は、コンテンツタイプがすでに終了しているリクエストについて、値がゼロのContent-LengthヘッダーをHTTP/2リクエスト自身のヘッダーテーブル（req->headers）に書き込んでいました。修正後は、リクエストごとのテーブル（r->headers_in）に書き込みます。コミットメッセージに説明はありませんが、スレッドに関する背景はRed Hatの説明から読み取れます。

到達可能な範囲

影響の有無は設定によって決まります。Red Hatは、ProtocolsディレクティブでHTTP/2を有効にしているサーバーのみが影響を受けるとしています。

Red HatのBugzillaのエントリによると、認証なしの攻撃者は「巧妙に細工したHTTP/2フレームを送信する」ことでこの脆弱性を引き起こします。このため、インターネットに公開され、HTTP/2を有効にしているhttpdは、最優先でパッチを適用すべき対象になります。なお、この表にはhttpdの前段に置かれるリバースプロキシは含まれていません。

HTTPdのRCE悪用：実証されたことと主張にとどまることの違い

Red HatのCVEページによると、公開された調査では「デフォルト設定のサーバーに対する信頼性の高いエクスプロイト」が示されたとされています。しかし、研究者名や詳細へのリンクがないため、これを検証することはできません。本稿の公開時点で、他のセキュリティ研究者やベンダーによる悪用の確認はありません。 

11月12日の16:00 UTC頃の時点で、このCVEをGitHubで検索すると4つのリポジトリが見つかりました。PoC、パッチ状況のトラッカー、そして検知または評価用のツール2件です。

このPoCが示しているのはヒープ破壊であり、コード実行ではありません。READMEは影響を「httpdの子プロセスにおけるヒープ破壊。リモートコード実行の可能性あり」と記述しています。 

その根拠は、ラボ環境でのビルドから得られたものです。

• 環境：debian:bookwormコンテナ上で、アップストリームのソースからhttpd 2.4.70をビルドし、Protocols h2c http/1.1を指定したprefork MPMで稼働
• 結果：PoCは6,080件のリクエストを送信しました。AddressSanitizerは5件のクラッシュを報告し、その中にはassign_headers()で割り当てられたヒープのuse-after-freeが含まれていました。ThreadSanitizerは、アロケーターの競合を31件報告しました。
• 修正版のビルド：2.4.71のビルドでは、いずれも確認されませんでした。
• トリガー：ボディなしで終了し、Content-Typeを持つ一方でContent-Lengthを持たないリクエストが、この不具合を引き起こします。修正コミットが変更したのは、まさにこのコードパスです。

READMEには、破壊されたメモリを制御できたという記載はなく、作者もエクスプロイトを公開していません。

結論として、認証なしのHTTP/2トラフィックにより、脆弱なhttpdをクラッシュさせ、ヒープを破壊できます。リモートコード実行も可能性はありますが、公に実証した例はまだありません。HTTP/2が有効な環境ではクラッシュが起こり得るものとして扱い、コード実行は現実的なリスクと捉えてください。

HTTPdのRCEによる影響

2026年11月13日時点で公になっている情報の中に、実環境での悪用、大規模なスキャンキャンペーン、公開RCEエクスプロイトを示すものはありません。一次情報から確認できるのは、次の点です。

• 認証なしRCEのリスク：Red Hatは、サーバーに到達できるリモートの攻撃者が、認証なしで任意のコマンドを実行できる可能性があるとしています。Bugzillaには、コマンドはhttpdプロセスの権限で実行されるとも記載されています。
• ワーカーのクラッシュ：公開PoCは、脆弱なビルドでhttpdの子プロセスをクラッシュさせます。
• 長期にわたる露出：影響範囲は2.4.55から始まるため、以前のHTTP/2の不具合に対してパッチを適用済みのサーバーでも、露出が残る場合があります。
• まだ修正がない経路：単体のmod_h2には修正版がありません。SUSE、openSUSE、Photon OS、CentOS Stream 10など複数のディストリビューションは、11月13日時点でもベンダーの修正を待っていました。

Sysdig SecureによるHTTPdのRCE検知

Sysdig Secureのユーザーは、CVE-2026-119618に対して3層の防御を利用できます。Threat Intelligenceのエントリは、影響を受けるApacheホストの稼働場所を示します。Vulnerability Managementは各ディストリビューションのベンダーアドバイザリと対応づけて管理します。Runtime Detectionsは、攻撃者が脆弱な環境に侵入した後で、エクスプロイトの成功がもたらす挙動を捕捉します。

オープンソースのFalcoによるHTTPdのRCE検知

Falcoが見るのはシステムコールであり、HTTP/2のフレームではありません。悪意のあるリクエストそのものは見えませんが、そのリクエストがホスト上で引き起こす挙動は見えます。具体的には、httpdプロセスによるシェルや想定外のバイナリの起動、想定外の外向き接続、機密性の高いパスへの書き込みなどです。

Webサーバーは正当な用途でも補助プロセスをforkするため、httpdを対象にしたルールは、誤検知を抑えるためにチューニングが必要です。前述の侵入後の対策も同様に適用できます。

推奨事項

まとめ

CVE-2026-119618は、httpdのHTTP/2モジュールにあるスレッド処理のバグであり、httpdが提供するアプリケーションの欠陥ではありません。ヒープ破壊とクラッシュは公になっています。コード実行は主張されているものの、公には実証されていません。しかし、だからこそ、到達可能性に基づいてパッチの優先順位を決めるべきです。防御側は、HTTP/2を有効にした、公開サーバーから着手してください。

セキュリティチームにとって、タイムラインは今回も重要な点です。2つのチームが8日違いで、独立にこのバグを報告しました。一方は自動化されたモデル駆動型のスキャナーで、もう一方は人間のチームでした。公表の翌日の11月12日までに、ヒープを破壊する公開PoCがGitHubに登場しています。「アドバイザリの公開」から「動作するエクスプロイトの登場」までの猶予は短く、組織はこうした通知に素早く対応できるよう備える必要があります。

今回の場合、最善の対応はまずパッチを適用することです。すべてのサーバーにパッチを適用して再起動するまでは、可能な限りHTTP/2を無効化し、ランタイム検知でギャップを埋めてください。ランタイムセンサーはヒープ破壊そのものを捉えられませんが、エクスプロイトが成功した後の挙動は検知できます。