ディープダイブ

Apache HTTP Server HTTP/2 RCE、2.4.71で修正（CVE-2026-119618）

Apache HTTP Serverのmod_http2のスレッド競合により、未認証のHTTP/2クライアントがメモリを破壊し、コードを実行できる可能性があります。2.4.71で修正されました。

Ostorlab Team 2026年11月12日

要点

Apache HTTP Serverのmod_http2は、接続スレッドと共有する表に合成のContent-Lengthヘッダーを書き込みます。Apacheはこの脆弱性をcriticalと評価し、Red HatはCVSS v3.1で9.8と採点しています。
HTTP/2をh2またはh2cで有効にしている2.4.55から2.4.70が影響を受けます。HTTP/1.1のみを話すサーバーは影響を受けません。
Red Hatは、公開研究がデフォルト設定のサーバーに対する信頼性の高いエクスプロイトを実証したと述べています。公開されたエクスプロイトコードはリンクされておらず、実際の悪用も知られていません。CVEは2026-11-12時点でCISA KEVにありません。
2.4.71または各ディストリビューションの修正パッケージに更新してください。できない場合はHTTP/2を無効にします。「修正方法」を参照してください。

影響を受けますか？

次の条件がすべて当てはまる場合に影響を受けます。

Apache HTTP Server 2.4.55から2.4.70を実行している。
mod_http2が読み込まれ、TLSではProtocols h2 http/1.1、平文ではh2cによりHTTP/2が有効になっている。
信頼できないクライアントが、直接またはHTTP/2を転送するプロキシ経由で、そのHTTP/2リスナーに到達できる。

HTTP/1.1のみに設定されたサーバーは影響を受けません。Red Hatは、RHEL 8以前はmod_http2が2.0.8より前であるため影響を受けないと述べています。

RHEL 9とRHEL 10は影響を受けますが、Importantと評価されています。Red Hatによると、各HTTP/2ストリームが別々のアロケーターから割り当てられるため、悪用の複雑さが大幅に増します。Apacheのアドバイザリはmod_h2 2.0.8から2.0.42を影響範囲として挙げており、2.4.71には修正済みモジュールが含まれます。

ブランチ	影響を受けるバージョン	修正バージョン
Apache HTTP Server 2.4.x	2.4.55から2.4.70	2.4.71

W3Techsによると、ApacheはWebサーバーが判明しているWebサイトの20.9%で使われています。影響範囲はその一部です。HTTP/2が有効である必要があります。

インストール済みのバージョンとHTTP/2の有効状態を確認します。

# Debian and Ubuntu
apache2 -v
apache2ctl -M | grep http2

# RHEL, Fedora and other RPM distributions
httpd -v
httpd -M | grep http2

# The Protocols directive shows whether h2 or h2c is enabled
grep -R "Protocols" /etc/apache2 /etc/httpd 2>/dev/null

コンテナでは、新しく取得したイメージではなく実行中のプロセスを確認します。

docker exec <container> apache2 -v
docker exec <container> apache2ctl -M | grep http2

RHELでは、修正後もhttpd -vはベースの2.4リリースを表示します。セキュリティ更新はmod_http2パッケージを変更するため、そのパッケージをアドバイザリと比較します。

rpm -q mod_http2

Red HatのCVEページによると、RHEL 9.9はmod_http2-2.0.26-7.el9_9.1を、RHEL 10.3はmod_http2-2.0.29-5.el10_3.1を提供します。これらのブランチの以前のmod_http2ビルドは影響を受けます。

修正方法

Apache HTTP Server 2.4.71に更新するか、各ディストリビューションが公開する修正済みのmod_http2パッケージをインストールします。Red Hatは2026-11-11にバックポートを公開しました。DebianのDSA-6620-1はDebian 13向けにapache2 2.4.71を挙げています。

パッケージを更新します。 ```bash # Debian and Ubuntu sudo apt update sudo apt install --only-upgrade apache2

# RHEL and Fedora sudo dnf update httpd mod_http2 2. 修正済みビルドを確認します。Debian 13では`apache2 -v`が2.4.71を表示します。それより古いDebianとUbuntuのリリースでは修正が既存のシリーズにバックポートされるため、`dpkg -s apache2`が表示するバージョンを、お使いのリリース向けのDSAまたはUSNに記載されたバージョンと比較します。RHELでは`rpm -q mod_http2`をアドバイザリのパッケージバージョンと比較します。 3. 新しいモジュールを読み込むためApacheを再起動します。bash sudo systemctl restart apache2 # Debian and Ubuntu sudo systemctl restart httpd # RHEL and Fedora ``` 4. Apacheを含むすべてのコンテナイメージを再構築して再作成します。実行中のコンテナが古いレイヤーを使っている場合、新しいイメージを取得するだけでは足りません。

ソースからビルドする場合は、Apache HTTP Serverプロジェクトの2.4.71リリースのtarボールを使用します。

すぐに更新できない場合はHTTP/2を無効にします。脆弱性はHTTP/2のリクエスト経路にあるため、その経路を外せば閉じられます。代償は多重化による性能上の利点を失うことです。

DebianとUbuntuではモジュールを無効にして再起動します。 bash sudo a2dismod http2 sudo systemctl restart apache2
RHELとFedoraではLoadModule http2_moduleの行をコメントアウトし、Protocolsにh2もh2cも含まれないことを確認してから再起動します。 bash sudo systemctl restart httpd
どのディストリビューションでもapache2ctl -M | grep http2またはhttpd -M | grep http2でモジュールが消えたことを確認します。出力がなければHTTP/2は無効です。

HTTP/2を終端し、HTTP/1.1をApacheへ転送するリバースプロキシは、バックエンドでこの経路を除去します。プロキシ自体が影響を受けるApacheを実行していれば、影響は残ります。HTTP/2の無効化は回避策であり、修正ではありません。修正済みモジュールが恒久的な解決策です。

根本原因は何ですか？

mod_http2はHTTP/2フレームを内部のrequest_recに変換し、assign_headers()は解析済みのリクエストヘッダーをリクエストのヘッダー表にコピーします。脆弱性は、ある分岐が合成のContent-Lengthヘッダーを、リクエスト固有のコピーではなく共有のコピー元表に書き込むことです。

関数はmodules/http2/h2_request.cにあります。以下は2.4.70タグのコードです。

static void assign_headers(request_rec *r, const h2_request *req,
                           int no_body, int is_connect)
{
    const char *cl;

    r->headers_in = apr_table_clone(r->pool, req->headers);

    if (req->authority && !is_connect) {
        ...
        apr_table_setn(r->headers_in, "Host", req->authority);
    }

    /* Unless we open a byte stream via CONNECT, apply content-length guards. */
    if (!is_connect) {
        cl = apr_table_get(req->headers, "Content-Length");
        if (no_body) {
            if (!cl && apr_table_get(req->headers, "Content-Type")) {
                /* If we have a content-type, but already seen eos, no more
                 * data will come. Signal a zero content length explicitly.
                 */
                apr_table_setn(req->headers, "Content-Length", "0");
            }
        }

req->headersは接続上のストリーム用に解析されたヘッダー表です。r->headers_inはリクエストのプールに割り当てられた複製であり、Apacheのモジュールが読む表です。関数はreqをconst h2_request *として受け取るため、変更してはいけません。この抜粋のHost分岐はr->headers_inに書き込んでおり、意図した対象を示しています。Content-Length分岐だけが例外です。

引き金は狭く、本文を必要としません。クライアントがHEADERSフレームにEND_STREAMを設定するとno_bodyが真になり、リクエスト本文は続きません。そのリクエストにContent-TypeがありContent-Lengthがなければ、この分岐が実行されます。

apr_table_setn()は新しいキーを追加するため、表が拡張され、表のプールにメモリが割り当てられます。そのプールは接続とストリームに属しますが、書き込みはストリームのワーカースレッドで実行されます。Red Hatは、ワーカースレッドが共有のロックなしアロケーターを通じて接続スレッドのメモリに書き込むと説明しています。

APRの表とプールはスレッドセーフではありません。同じ表への並行した割り当てや走査はヒープを破壊する可能性があります。アドバイザリはこの脆弱性を不適切な同期による並行実行の問題（CWE-362）に分類し、Apacheの説明はassign_headers()を直接名指ししています。

どのように悪用されますか？

攻撃者はHTTP/2接続を開きます。TLSではh2、平文ではh2cを使います。
攻撃者はその接続で多数のHEADERSリクエストを同時に送ります。各リクエストは:method、:path、:authority、Content-Typeを持ち、Content-LengthなしでEND_STREAMを設定します。
各リクエストはno_bodyが有効な状態でワーカースレッドのassign_headers()に到達します。ワーカーは共有のreq->headers表にContent-Length: 0を追加します。
ワーカーがその表に割り当てている間、接続スレッドや他のワーカーが同じ表とプールを読んだり割り当てたりできます。この競合がヒープを破壊します。
Apacheは、この破壊がリモートコード実行につながる可能性があると述べています。ワーカーまたはサーバープロセスのクラッシュがより単純な結果です。

アドバイザリはエクスプロイトコードを公開していません。Red Hatは、公開研究がmod_http2を有効にしたデフォルト設定のサーバーに対する信頼性の高いエクスプロイトを実証したと述べ、その理由でcriticalと評価しています。2026-11-12時点で実際の悪用は知られていません。

攻撃の流れは？

未認証のHTTP/2クライアントが、Content-Typeを持ちContent-Lengthを持たない本文なしのリクエストを送ります。ワーカーの合成ヘッダー書き込みが接続スレッドのアロケーターと競合し、ヒープが破壊されます。

flowchart LR
    A["HTTP/2クライアント<br/>HEADERS + END_STREAM"] --> B["mod_http2が<br/>no_bodyを設定"]
    B --> C["assign_headers()<br/>Content-Typeあり、Content-Lengthなし"]
    C --> D["apr_table_setn(req->headers)<br/>共有表、ワーカースレッド"]
    D --> E["接続スレッドの<br/>共有アロケーター"]
    E --> F["ヒープの破壊"]
    F --> G["クラッシュまたは<br/>リモートコード実行"]

攻撃者に何ができますか？

HTTP/2リスナーに到達できる未認証の攻撃者は、サーバーをクラッシュさせることができます。ヒープの破壊を有用なプリミティブに成形できれば、Apacheを実行するユーザーとしてコードを実行できます。Apacheのアドバイザリは、この脆弱性がリモートコード実行につながる可能性があると述べています。Red Hatはさらに踏み込み、悪用に成功すれば任意のコマンド実行、サーバープロセスの完全な制御、機密データへのアクセスが可能になると述べています。

Red Hatはこの脆弱性をCVSS v3.1 9.8、CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hと評価しています。

条件は「影響を受けますか？」に挙げたとおりです。影響を受ける2.4リリース、mod_http2の読み込み、HTTP/2の有効化、ネットワークからの到達性が必要です。攻撃者にアカウントもユーザー操作も不要です。

悪用は競合に勝つことに依存するため、信頼性は負荷、アロケーターの配置、同時ストリーム数によって変わります。Red HatがRHEL 9とRHEL 10をCriticalではなくImportantと評価するのはそのためです。ただし影響を受けることには変わりません。

クラッシュはサービス拒否であり、コード実行ではありません。情報源はコード実行を可能と説明し、Red Hatは研究で実証されたと述べています。どちらの情報源も動作するエクスプロイトや被害報告を公開していません。

修正が機能する理由

パッチはassign_headers()の1行を変更し、合成ヘッダーをリクエスト固有の複製に書き込みます。

@@ -350,7 +350,7 @@ static void assign_headers(request_rec *r, const h2_request *req,
                 /* If we have a content-type, but already seen eos, no more
                  * data will come. Signal a zero content length explicitly.
                  */
-                apr_table_setn(req->headers, "Content-Length", "0");
+                apr_table_setn(r->headers_in, "Content-Length", "0");
             }
         }

r->headers_inはリクエストのプールに割り当てられ、このストリームを処理するワーカーだけが使います。共有のreq->headers表は複製の作成後に変更されないため、ワーカーは接続スレッドのメモリに書き込まなくなります。合成ヘッダーは下流のモジュールに引き続き届きます。モジュールはr->headers_inを読むからです。

この変更はassign_headers()内でreq->headersに書き込む唯一の箇所を覆います。同じ関数のもう一つのヘッダー書き込みであるHostは、すでにr->headers_inを使っていました。修正はHTTP/2のフレーミングやリクエスト本文の処理を変えません。

侵害されたかどうかを確認するには？

この脆弱性について公開された侵害指標はありません。悪用に成功しても、使った破壊済みメモリ以外に痕跡が残らないことがあります。失敗した試行はワーカーのクラッシュだけを残すかもしれません。

Apacheのエラーログでクラッシュと子プロセスの異常終了を調べます。特に修正前にHTTP/2を公開していたサーバーで確認します。

grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/apache2/error.log
grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/httpd/error_log

systemdのホストではApacheバイナリのコアダンプを一覧します。

coredumpctl list apache2
coredumpctl list httpd

クラッシュは手がかりであり、悪用の証拠ではありません。他のバグやリソース制限もワーカーを終了させるからです。影響を受けるビルドを実行していたHTTP/2サーバーでクラッシュが繰り返される場合は、再起動する前にログとコアダンプを保存してください。調査が終わるまでホストを侵害された可能性があるものとして扱います。

年表

2026-10-26: AnthropicのOSS ScannerがANT-2026-MAPKT6MZとしてApacheセキュリティチームに報告します。
2026-11-03: Google Cloud Vulnerability ResearchのAnthony Weems氏とSimon Scannell氏が独立に報告します。
2026-11-09: 修正がmasterのコミット5ed3928のcherry-pickであるコミット824beabとして2.4.xブランチに入ります。
2026-11-11: Apacheが2.4.71とCVE-2026-119618のアドバイザリを公開します。Red Hatも同日に修正済みのmod_http2パッケージとアドバイザリを公開します。

最初の報告から修正版まで16日。 — 最初の報告から修正版までの経過。16日後。出典: Apache HTTP Serverセキュリティページと修正コミット、2026年11月12日確認

よくある質問

HTTP/1.1のみのサーバーは影響を受けますか？

いいえ。脆弱性はHTTP/2のリクエスト経路にあります。mod_http2を読み込んでいてもHTTP/1.1だけを交渉するサーバーはassign_headers()に到達しません。

リバースプロキシがTLSを終端しています。Apacheバックエンドは影響を受けますか？

プロキシとApacheの間のプロトコルによります。プロキシがHTTP/2を転送するならバックエンドは影響を受けます。HTTP/1.1を転送するならバックエンドではこの経路は閉じますが、プロキシ自体が影響を受けるApacheを実行している可能性があります。

公開エクスプロイトはありますか？

ApacheのアドバイザリにもCVEレコードにも公開エクスプロイトコードはリンクされていません。Red Hatは、公開研究がmod_http2を有効にしたデフォルト設定のサーバーに対する信頼性の高いエクスプロイトを実証したと述べています。

CVE-2026-119618はCISA KEVにありますか？

いいえ。2026-11-12時点でCISAのKnown Exploited VulnerabilitiesカタログにこのCVEはなく、実際の悪用も知られていません。

どのRHELバージョンが影響を受けますか？

RHEL 9とRHEL 10が影響を受け、Importantと評価されています。RHEL 8以前はmod_http2が2.0.8より前であるため影響を受けません。各ブランチについてRed Hatのアドバイザリに記載されたmod_http2パッケージをインストールしてください。

RHELの更新後も`httpd -v`が2.4.57を表示するのはなぜですか？

Red Hatはhttpdのバージョンを変更せず、修正をmod_http2パッケージにバックポートしました。rpm -q mod_http2を修正済みパッケージのバージョンと比較してください。httpdのバージョン文字列ではありません。

参考資料

Apache HTTP Serverセキュリティページ、CVE-2026-119618アドバイザリ、2026-11-11公開: https://httpd.apache.org/security/vulnerabilities_24.html (2026年11月12日確認)
CVE-2026-119618レコード、Apache Software Foundation CNA、2026-11-11公開: https://www.cve.org/CVERecord?id=CVE-2026-119618 (2026年11月12日確認)
2.4.xブランチの修正コミット、824beab、2026-11-09: https://github.com/apache/httpd/commit/824beab9b9424d6cfb29595248fdbf6c3dddeab1 (2026年11月12日確認)
masterのupstream修正コミット、5ed3928、2026-11-09: https://github.com/apache/httpd/commit/5ed39287660daacd1233cb9bbc984b25fa9a4fe3 (2026年11月12日確認)
Red HatのCVE-2026-119618ページ、CVSS v3.1 9.8と修正済みmod_http2パッケージ、2026-11-11公開: https://access.redhat.com/security/cve/CVE-2026-119618 (2026年11月12日確認)
Debianセキュリティトラッカー、CVE-2026-119618、DSA-6620-1、修正済みapache2 2.4.71: https://security-tracker.debian.org/tracker/CVE-2026-119618 (2026年11月12日確認)
W3Techs、Apacheの使用率、Webサーバーが判明しているWebサイトの20.9%: https://w3techs.com/technologies/details/ws-apache (2026年11月12日確認)

ostorlab/KEV オープンソース

# 無料のオープンソース：このような既知の悪用された脆弱性がないか、自分のホストをスキャンしましょう。

$ pip install -U ostorlab
$ git clone https://github.com/Ostorlab/KEV && cd KEV
$ ostorlab scan run --install -g agent_group.yaml domain-name example.com

Ostorlab KEVは無料のオープンソース（Apache-2.0）です。1つのコマンドで、CISA KEVカタログ、Google Tsunami、バグバウンティプログラム由来の脆弱性を対象に、Nuclei、Tsunami、Nmap、Asteroid、Metasploitの検出器を実行します。

github.com/Ostorlab/KEV

タグ：

security, CVE, Apache, HTTP/2, memory corruption, vulnerability

要点