この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
本命は CVE-2026-23918。HTTP/2 のストリーム処理で起きる二重解放(Double Free)で、CVSS 8.8 HIGH。リモートコード実行(RCE)の可能性まで踏み込んだ書きぶりが、Apache 公式・NVD・oss-security の3経路で出ています。
ただ、ここを「未認証RCEだ」と一足飛びに断定するのは、NVDの CVSS ベクターを読む限りやや踏み込みすぎだと思っています。後で詳しく書きますが、NVD は PR:L(低権限を要する)です。一方で第三者ベンダーの解説には「unauthenticated」と書くものもあり、扱いが割れています。
20年以上 Linux サーバーの現場にいますが、HTTP/2 の double free でここまで CVSS が振れるのは記憶にないレベルです。Apache HTTP Server を本番で使っているなら、11件の俯瞰よりも CVE-2026-23918 をどう塞ぐかに時間を割いた方が筋がいい。
この記事のポイント
- Apache 2.4.67 で修正された CVE は11件。本命は CVE-2026-23918(HTTP/2 二重解放、CVSS 8.8 HIGH)。
- 影響を受けるのは 2.4.66 のみ。古いバージョンを使っているサーバーは別の意味で危険ですが、CVE-2026-23918 単体の対象範囲は限定的です。
- 認証要否は両論あります。NVDではPR:L(低権限要)。一方ベンダーレポートには「unauthenticated」と書くものもある。運用環境次第で実質ほぼ無認証に近いケースもあるので、「PR:Lだから安心」という読み方は危険です。
- 「mod_http2 を無効化すれば塞げる」は Apache 公式アナウンスの暫定回避策ではありません。ベンダー解説の援用です。本記事でも区別して書きます。
- 残り10件は Moderate×2(mod_rewrite 権限昇格、mod_auth_digest タイミング攻撃)と Low×8。AJP系が多いので、リバースプロキシでAJPを使っていない環境なら影響は限定的です。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
CVE-2026-23918 が本命である理由
11件のうち、なぜこれだけ別格なのか
Apache 公式の Severity 分類で Important が付いているのは、11件のうち CVE-2026-23918 ただ1件です。残りは Moderate が2件、Low が8件。NVD の CVSS でも 8.8 HIGH は CVE-2026-23918 だけが突き抜けています。これがどういう意味かというと、パッチ提供前にエクスプロイト研究の標的になりやすい1件がここに集中している、ということです。RCE の可能性に言及されている脆弱性は、攻撃者側の優先度が一段違います。残り10件のうちで Low が8件を占めているのも、対比としてはっきり読み取れる構図です。
私が今回の11件をざっと読んで「これは別格だ」と判断したのも、Severity 分類だけでなく「Double Free → Use After Free → RCE」というよくある攻撃チェーンが、HTTP/2 のストリーム処理という外向きで常にトラフィックを浴びる経路に乗っている点でした。AJP の Heap Over-Read(Low)とは攻撃面の広さがまったく違います。
oss-security と NVD で温度差はあるが、本命扱いは一致
oss-security メーリングリストの 2026-05-04 投稿、NVD の CVE-2026-23918 詳細、Apache 公式アナウンスの3つを並べても、本命がこの1件であるという位置づけは揺れていません。表現の温度差は若干あります。- Apache 公式: Severity Important、Description は「early reset on h2_mplx で double free、可能なら RCE」
- NVD: CVSS 8.8 HIGH、CWE-415(Double Free)、PR:L
- oss-security: 修正コミットは2025-12-11時点ですでに適用済み、公開アナウンスは2026-05-04
CVE-2026-23918 の正体(CWE-415 二重解放 + mod_http2)
脆弱箇所は h2_mplx.c のクリーンアップ経路
脆弱コードパスは mod_http2 内の h2_mplx.c。HTTP/2 のストリームをマルチプレクサに登録する直前に、不正な形式の early reset を投げると、ストリームの片付け処理が二重に走るというものです。具体的には次の手順を踏むと発動します(防御目的のため経路を整理)。
- クライアントが HEADERS フレームを送る
- HEADERS フレームの直後に、ゼロでないエラーコードを乗せた RST_STREAM を送る
- このタイミングでストリームがまだマルチプレクサに登録される前だと、h2_mplx 側のクリーンアップ経路が誤って二重に走る
CVSS 8.8 HIGH の中身を読む
NVD のベクターは CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H です。一つずつ意味を読みます。| 項目 | 値 | 意味 |
|---|---|---|
| AV: Attack Vector | N(Network) | リモートからネットワーク経由で攻撃可能 |
| AC: Attack Complexity | L(Low) | 攻撃の前提条件が少ない、再現性が高い |
| PR: Privileges Required | L(Low) | 低い権限が必要。「未認証」ではなくユーザー一段以上の権限が必要、というのがNVDの判断 |
| UI: User Interaction | N(None) | 被害者側の操作は不要 |
| S: Scope | U(Unchanged) | 影響範囲は同一スコープ内 |
| C/I/A | すべて H(High) | 機密性・完全性・可用性のすべてに高い影響 |
ここで判断が割れているのが PR:L です。NVD は「攻撃者は何らかの認証されたコンテキストを持っている必要がある」と判断しています。一方、第三者ベンダーの解説では「unauthenticated remote attacker」と書くものが複数あります。
私の理解では、HTTP/2 のフレームを生で組み立てて送る前提では、認証経路を経ずに HTTP/2 接続を確立できる構成(公開Webサーバーの一般経路)なら、実質的には未認証に近い悪用ができてしまう可能性があります。NVD が PR:L と振っているのは、Apache のリクエスト処理上で「最低限の認証コンテキスト」が形式的に成立しているケースを想定した評価だと読むのが筋ですが、ここは公式と NVD で記載の歩調が完全に揃ってはいません。
記事で扱う以上、「NVDではPR:Lだが、運用環境次第では実質無認証に近い悪用が成立しうる」という両論で押さえておく方が安全です。「PR:Lだから心配ない」という読み方は危険、と覚えておいてください。
影響範囲(2.4.66のみ・パッチ提供状況)
影響を受けるバージョンは 2.4.66 のみ
CVE-2026-23918 の影響対象は Apache HTTP Server 2.4.66 のみです。Apache 公式・NVD・oss-security のいずれも「2.4.66」で一致しています。ここを「2.4.0〜2.4.66 すべてが対象」と誤読しないでください。原因となった mod_http2 のリグレッションは 2.4.66 で混入したもので、2.4.65 以前のバージョンには CVE-2026-23918 そのものは存在しません。修正コミット自体は 2025年12月時点ですでに mod_http2 側で適用済み、公開アナウンスがそこから5ヶ月遅れて 2026-05-04 に出た、という時系列です。
ただし、2.4.65 以前を使っているサーバーには別の意味で問題があります。今回の11件のうち 9件は ≤2.4.66 もしくはより広い範囲(2.4.0〜、2.4.30〜 等)が対象になっており、CVE-2026-23918 を踏まない代わりに別の Low/Moderate を全部踏みます。「2.4.66ではないから安心」ではなく、「2.4.67 にしないと残り10件が残る」と読むのが正しい。
パッチ提供状況
公式パッチは Apache HTTP Server 2.4.67 です。ディストロパッケージは2026-05-12時点で順次配布が進んでいます。本番に当てる前には必ず各ディストロの公式アドバイザリで最新の配布状態を再確認してください。本記事でも参考情報として配布動向に触れますが、配布タイミングは日々動く領域です。
他10件の俯瞰(Severity別の整理)
残り10件は Moderate 2 / Low 8
CVE-2026-23918 以外の10件を Severity 別に整理します。| CVE | 概要 | Severity | 影響バージョン |
|---|---|---|---|
| CVE-2026-24072 | mod_rewrite の ap_expr 経由の権限昇格 | Moderate | ≤2.4.66 |
| CVE-2026-33006 | mod_auth_digest のタイミング攻撃 | Moderate | ≤2.4.66 |
| CVE-2026-28780 | mod_proxy_ajp の ajp_msg_check_header() バッファオーバーフロー | Low | ≤2.4.66 |
| CVE-2026-29168 | mod_md の OCSP レスポンス制限不足 | Low | 2.4.30〜2.4.66 |
| CVE-2026-29169 | mod_dav_lock の indirect lock による NULL ポインタ逆参照 | Low | ≤2.4.66 |
| CVE-2026-33007 | mod_authn_socache のクラッシュ(NULLポインタ逆参照) | Low | 2.4.0〜2.4.66 |
| CVE-2026-33523 | 複数モジュール: HTTP レスポンス スプリッティング(不正な status line の転送) | Low | 2.4.0〜2.4.66 |
| CVE-2026-33857 | AJP getter 関数の Off-by-one OOB Read | Low | ≤2.4.66 |
| CVE-2026-34032 | mod_proxy_ajp の Heap Buffer Over-Read(ajp_msg_get_string、NULL終端不足) | Low | ≤2.4.66 |
| CVE-2026-34059 | mod_proxy_ajp の Heap Over-Read / memory disclosure(ajp_parse_data) | Low | ≤2.4.66 |
Moderate 2件は「環境次第」で本命級に化ける
Low 8件のうち5件が mod_proxy_ajp 系です。AJP バックエンドを使っていなければ影響を受けません。一方で Moderate 2件は、使っているサイトでは無視できない性質を持っています。CVE-2026-24072(mod_rewrite ap_expr)は、書き換えルール内で評価される式に細工することで、本来許可されないコンテキストでの実行に持ち込める、という権限昇格系です。
RewriteRule を本番で多用している環境では、設定の見直しと合わせて 2.4.67 への昇格が必要です。CVE-2026-33006(mod_auth_digest タイミング攻撃)は、ダイジェスト認証を使っている環境限定ですが、パスワード比較のタイミングサイドチャネルで情報が漏れます。Digest 認証を残しているなら、これも 2.4.67 への更新で塞ぎます。
Low 8件の優先度判断
mod_proxy_ajp の Low が5件、mod_md、mod_dav_lock、mod_authn_socache、HTTP レスポンス スプリッティングが各1件。AJP を使っていない、mod_md(Let's Encrypt 連携)を使っていない、WebDAV を有効化していない、というケースが多いと思います。それでも、「使っていないモジュールが入っているだけ」で攻撃面が広がるのは脆弱性管理の基本です。今回の機会に
apachectl -M でロード中モジュールを棚卸しして、不要なものは外す方向で動く方が筋がいいと思います。
現場でやること①バージョン確認
「自分のApacheは2.4.66か?」を1コマンドで見る
まず、走っている Apache のバージョンを確認します。$ httpd -v Server version: Apache/2.4.66 (Unix) Server built: Mar 12 2026 10:32:45 # Debian/Ubuntu 系では apache2 $ apache2 -v Server version: Apache/2.4.66 (Ubuntu)
httpd -v の出力に 2.4.66 が出れば、CVE-2026-23918 の直接の対象です。2.4.65 以前なら CVE-2026-23918 自体は踏みませんが、残り10件のうち多数が対象に入ります。ディストロパッケージのビルド番号で見る
ディストロパッケージは、独自にバックポートして「2.4.62-12.el9_5」のようなパッケージ番号を振っていることがあります。httpd -v の数字だけでは判断できないので、パッケージ管理ツールで changelog を見る方が確実です。# RHEL / AlmaLinux / Rocky 系 $ rpm -q httpd $ rpm -q --changelog httpd | grep -E "CVE-2026-23918|2\.4\.67" # Debian / Ubuntu 系 $ dpkg -l | grep apache2 $ apt changelog apache2 | grep -E "CVE-2026-23918|2\.4\.67"
HTTP/2 を有効化しているかを確認
CVE-2026-23918 は mod_http2 経由の脆弱性なので、そもそも HTTP/2 を有効化していなければ攻撃経路が成立しません。設定で確認します。# ロードされているモジュールに http2 があるか $ apachectl -M 2>/dev/null | grep -i http2 http2_module (shared) # 設定ファイル内に Protocols ディレクティブがあるか $ grep -rn "Protocols" /etc/httpd/conf.d/ /etc/httpd/conf/ # Debian/Ubuntu の場合 $ grep -rn "Protocols" /etc/apache2/
Protocols h2 http/1.1 のように h2 が含まれていれば HTTP/2 有効です。HTTP/2 を使っていない(http/1.1 のみ)の構成なら、CVE-2026-23918 単体の影響は受けません。それでも残り10件が残るので、2.4.67 への更新自体は必要です。現場でやること②アップデート手順
ディストロ別の手順
パッケージで運用しているサーバーは、各ディストロの apt / dnf 系コマンドで更新できます。# Debian / Ubuntu 系 $ sudo apt update $ sudo apt install --only-upgrade apache2 apache2-bin apache2-data $ sudo systemctl restart apache2 # AlmaLinux / Rocky / RHEL 系 $ sudo dnf upgrade httpd httpd-tools mod_http2 $ sudo systemctl restart httpd # Amazon Linux 2023 $ sudo dnf upgrade httpd mod_http2 $ sudo systemctl restart httpd
$ httpd -v Server version: Apache/2.4.67 (Unix) # またはディストロパッケージのバックポート番号 # 再起動でメモリ上のプロセスが新バージョンになったかを確認 $ ps -eo pid,command | grep -E "httpd|apache2" | grep -v grep $ sudo apachectl status | head
httpd -v の表示が更新されていることと、systemctl status で起動時刻が更新時刻に近いことを揃えて確認します。ソースビルドの場合は mod_http2 の同時更新を忘れない
Apache HTTP Server をソースビルドで運用しているケースでは、本体 2.4.67 への入れ替えだけでなく、mod_http2 が同梱版か外付け版かを確認してください。2.4.x 系では mod_http2 が同梱されているため、Apache 本体のビルドアーカイブを 2.4.67 に差し替えれば mod_http2 も同時に更新されます。一方、過去に mod_http2 を別途 nghttp2 連携で外付けビルドしているケースでは、外付け側が古いままになっていると意味がないので注意してください。
# 外付けの場合、mod_http2.so の更新日とビルド情報を確認 $ ls -l /usr/local/apache2/modules/mod_http2.so $ apachectl -M | grep http2
現場でやること③暫定回避(mod_http2無効化はベンダー解説)
Apache 公式アナウンスには暫定回避策の明示なし
ここは慎重に書きます。CVE-2026-23918 の Apache 公式アナウンス(vulnerabilities_24.html)には、明示的な暫定回避策(ワークアラウンド)の記載がありません。公式の指示は「2.4.67 にアップグレードせよ」の一択です。
一方で、複数の第三者ベンダー解説(SecurityAffairs、Indusface、Hadrian 等)は 「mod_http2 を無効化すれば脆弱コードパスを実行しない」と書いています。これは技術的には正しい(mod_http2 が読み込まれなければ h2_mplx.c のコードは走らない)のですが、Apache 公式の指示ではないという点だけは明確に区別してください。
本当に再起動枠が即取れないときの選択肢
本番のメンテナンスウィンドウがどうしてもすぐに取れない場合、ベンダー解説で紹介されている暫定策として mod_http2 の無効化があります。ただし公式の暫定策ではないこと、HTTP/2 利用サイトでは業務影響が大きいことを踏まえて判断してください。# Debian / Ubuntu 系 $ sudo a2dismod http2 $ sudo systemctl restart apache2 # RHEL / AlmaLinux 系: Protocols ディレクティブから h2 を外す # /etc/httpd/conf.d/ssl.conf 等の該当箇所 # Protocols h2 http/1.1 # ↓ # Protocols http/1.1 $ sudo systemctl restart httpd
私の手元で言えば、HTTP/2 を本番で使っているサーバーは限定的なので、影響範囲を確認したうえで「2.4.67 への更新をメンテナンスウィンドウで待てるサーバーは待つ」「即時で塞ぎたいサーバーは mod_http2 を一時停止する」という二段運用にしました。
AJP系を使っていない環境は影響限定
念のため添えておきます。今回の11件のうち5件は mod_proxy_ajp 系の Low です。Tomcat 等の AJP バックエンドを使っていない構成では、LoadModule proxy_ajp_module を外しておけば、これらの脆弱性はそもそも実行経路を持ちません。# AJP モジュールがロードされているか確認 $ apachectl -M | grep -i ajp # Debian/Ubuntu で無効化 $ sudo a2dismod proxy_ajp
教訓・運用への示唆
HTTP/2 の double free は「想像していたより速く再来する」
HTTP/2 系の脆弱性は、過去にも Rapid Reset(CVE-2023-44487)のように「ストリームの早期リセットを起点にする」種類のものが出ています。今回の CVE-2026-23918 は double free という別軸ですが、「early reset を引き金にして h2_mplx を揺さぶる」という発想の系譜は重なっています。受講生のひとりに「HTTP/2 の脆弱性はもう出尽くしたかと思っていました」と言われたのですが、それは違うと思います。HTTP/1.1 と比べて HTTP/2 のステート機械は複雑で、ストリームのライフサイクル管理に間違いが入り込む余地は今後も残り続けるはずです。
「mod_http2 を有効化しているサーバー」の棚卸しを今やる
Apache HTTP Server の設定では、HTTP/2 が デフォルトで有効になっていないが、SSL/TLS 設定の中でProtocols h2 http/1.1 として案内されているケースがあります。SSL 設定をコピペで増やしていったサーバーは、本人が認識していないところで HTTP/2 を有効化していることが珍しくない。# 全 VirtualHost を横断して Protocols 行を grep $ grep -rn "Protocols" /etc/httpd/ /etc/apache2/ 2>/dev/null
「公式の暫定策」と「ベンダー解説の暫定策」を区別する習慣をつける
今回、ベンダー記事の多くが「mod_http2 を無効化」と書いていました。技術的には正しいのですが、Apache 公式が暫定策として案内していないものを「公式の対応」として現場に伝えると、社内・お客様への説明が崩れる原因になります。私の現場での運用ルールは 「公式アナウンスと一次情報に書いてあること以外は、ベンダー解説と明示して伝える」です。今回も「mod_http2 を無効化する案がベンダー解説で紹介されていますが、Apache 公式の指示は『2.4.67 にアップグレード』の一択です」というかたちで上にエスカレーションしました。
今日のチェックリスト
最後に、今日のうちに済ませておきたいことをチェックリストで残します。httpd -vまたはapache2 -vで現行バージョンを確認し、2.4.66 かどうかを判定するapachectl -Mとgrep -rn "Protocols"で HTTP/2 の有効化状態を棚卸しする- 2.4.66 で HTTP/2 を有効化しているサーバーは最優先で 2.4.67 へ更新
- 更新後は
httpd -vとsystemctl statusで「メモリ上のプロセスが新バージョンになっている」ことまで確認 - 2.4.67 への更新が直ちに取れないサーバーは、ベンダー解説の暫定策として mod_http2 無効化が紹介されていることを把握。ただし公式の暫定策ではないこととHTTP/2利用サイトの業務影響を踏まえて判断
- AJP を使っていない構成は
a2dismod proxy_ajp/ モジュール無効化で攻撃面を縮小 - mod_rewrite を多用しているサイトは CVE-2026-24072(Moderate)も同時に塞ぐ前提で更新計画を立てる
- Apache 公式セキュリティ情報: https://httpd.apache.org/security/vulnerabilities_24.html
- NVD CVE-2026-23918: https://nvd.nist.gov/vuln/detail/CVE-2026-23918
- oss-security メーリングリスト(2026-05-04): https://www.openwall.com/lists/oss-security/2026/05/04/19
- MITRE/CVE.org: https://www.cve.org/CVERecord?id=CVE-2026-23918
Apache 2.4.67への更新、自信を持って本番に当てられますか?
httpd -v、apachectl -M、Protocols ディレクティブの棚卸し、mod_http2 の判断、ディストロ別のパッケージ更新。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます