Apache HTTP Server 2.4の脆弱性まとめ｜CVE-2026-119618・33523ほか2.4.67〜2.4.71の該当判定と更新手順【2026年11月】

Apache HTTP Server 2.4系は2026年に4回のセキュリティリリースを出しました。5月4日の2.4.67でCVE-2026-33523（HTTPレスポンス分割）やHTTP/2の二重解放CVE-2026-23918など11件、6月8日の2.4.68で13件、10月1日の2.4.69で20件、そして11月11日の2.4.71でmod_http2のcritical（CVE-2026-119618）を含む3件が修正され、2026年11月12日時点の最新版は2.4.71です。間の2.4.70にはCVE付きの修正がありません。やっかいなのは、Apacheセキュリティチームの深刻度とNVDに載るCISA-ADPのCVSSが大きく割れる点と、ディストリの版番号だけでは修正済みか判断できない点です。本記事は、各CVEの影響版と前提条件を押さえたうえで、版番号・有効モジュール・パッケージの3段で自社が該当するかを判定し、RHEL系・Debian/Ubuntu系・ソースビルドそれぞれで更新するまでを、環境確認と更新に使うコマンド例とともに示します。

まとめ：2026年11月時点の結論は2.4.71相当への更新とパッケージ別の確認

• 上げる先は2.4.71。10月の更新で2.4.69に上げた環境も、そのままではmod_http2のcritical CVE-2026-119618（影響2.4.55〜2.4.70）が残る。2.4.70はCVE付きの修正を含まないので、経由する意味はない。
• 2.4.71の3件はモジュール単位で効き方が違う。HTTP/2を有効にしていれば119618（ヒープ破壊・RCEのおそれ）、mod_mdで証明書を自動取得していれば106023（子プロセスのクラッシュ）、2.4.69・2.4.70でVirtualDocumentRootを使っていれば109163（1バイトのスタック書き込み）が該当する。
• RHEL 9系はmod_http2の更新で2件がまとめて片づく。2026年11月11日のRHSA-2026:98981（mod_http2-2.0.26-7.el9_9.1）で、119618と、10月時点で未修正だったCVE-2026-57941の両方が修正された。Debianは12・13とも3件が未修正（2026年11月12日時点）。
• Apache評価が「low」でもCISA-ADPは9.8のものがある。mod_proxy_ajpのCVE-2026-28780はApache評価lowだが、NVDのCISA-ADPは9.8 CRITICAL。優先度はCVSSの数値ではなく、有効モジュールと構成で決める。
• CVE-2026-33523（2.4.0〜2.4.66）は信頼できない・侵害されたバックエンドへ中継する構成が前提。Red HatはRHEL 6〜10のhttpdで修正を保留（Fix deferred）としており、更新しても残る。
• ディストリ版は版番号だけで判定できない。Ubuntu 24.04は2.4.58のまま2.4.69相当の修正まで取り込み済み、RHEL 9系はhttpd 2.4.62のうえHTTP/2の修正はmod_http2という別パッケージに入る。
• 2026年のhttpdのCVEはCISA KEV未掲載（2026年11月10日版）。ただしCVE-2026-49975はPoCが公開済み。

2.4.68・2.4.69で修正された33件をCVE番号ごとに並べ、Apache・Red Hat・CISA-ADPの3者評価とディストリ別の修正状況を表にしたものはJVNが公表したApache 2.4系複数脆弱性のCVE別影響範囲にまとめています。本記事は「どのCVEに注意し、では何を打てばよいか」の判定と手順に絞ります。

2.4.71の修正3件：mod_http2のcriticalと2.4.69由来の不具合

2.4.71は2026年11月11日に公開され、Apache公式のセキュリティ情報ではcritical 1件・important 1件・low 1件の計3件が修正対象です。国内では翌12日にJVNVU#90805396が公開されました。NVDの3件は2026年11月12日時点でまだ受付段階（Received）で、CISA-ADPのCVSSは付いていません。そのため下表はRed Hatの評価を並べています。

3件とも、該当モジュールを読み込んでいなければ攻撃経路はありません。逆に、2.4.69へ上げたことで新たに入り込んだ不具合（109163）も含まれるため、「10月に更新したから今回は対象外」という判断は成り立ちません。なお2.4.70は変更履歴（CHANGES_2.4）に節があるものの、CVE番号の付いた修正は無く、mod_authnz_ldapのWindowsでのクラッシュ修正やmod_dav_lockのヒープ溢れ修正（CVEなし）などの不具合修正にとどまります。

CVE-2026-119618：mod_http2のヘッダー割り当て時の同期不備

問題の箇所は、HTTP/2で受けたリクエストのヘッダーをhttpd側のリクエストへ設定する関数 assign_headers() です。

Apacheの件名は「mod_http2: heap corruption and RCE in assign_headers」で、共有資源の同期不備（CWE-362）によりヒープが壊れ、リモートコード実行に至るおそれがあるとしています。影響はhttpd 2.4.55〜2.4.70に加え、GitHubで単体配布されているmod_h2の2.0.8〜2.0.42です。報告者にはAnthropicのOSSスキャナとGoogle Cloudの脆弱性調査チームが並び、報告から公開までは約2週間でした。

2.4.x向けの修正コミット824beabは、modules/http2/h2_request.c の1行だけを変えています。

/* Content-Type はあるが本文が既に終わっているHTTP/2リクエストに
 * Content-Length: 0 を補う箇所。書き込み先の表を差し替えた */
- apr_table_setn(req->headers, "Content-Length", "0");
+ apr_table_setn(r->headers_in, "Content-Length", "0");

書き込み先が、HTTP/2側で組み立てたリクエスト情報の表（req->headers）から、処理中のリクエストが持つ表（r->headers_in）へ移されました。CWE-362の分類と合わせて読むと、別の処理からも参照されうる表を同期なしに書き換えていたことが問題だったと読めます。攻撃側が細工するのはHTTP/2のリクエストヘッダだけなので、インターネットに面してHTTP/2（h2）を有効にしているサーバは最優先で更新してください。

GitHub版のmod_h2を自前でビルドして差し替えている構成は注意が要ります。2026年11月12日にmod_h2のリリース一覧を確認した時点で最新は2.0.42（5月29日公開）で、これは影響範囲の上限そのものです。修正を含むリリースが出るまでは、httpd 2.4.71同梱のmod_http2へ戻すか、後述の手順でHTTP/2を止めるかのどちらかになります。

CVE-2026-106023：mod_mdのNULL参照と子プロセスのクラッシュ

Apacheの件名は「mod_md NULL pointer dereference leads to child process crash」で、評価はimportantです。

mod_mdはACMEで証明書を自動取得・更新するモジュールです。修正コミット1b47e95を見ると、ACMEのHTTP-01チャレンジ（/.well-known/acme-challenge/）と証明書状態の応答を処理する箇所に、Hostヘッダが無いリクエストを受け流す判定が足されています。HTTP/1.0のようにHostヘッダを送らないリクエストで、ホスト名がNULLのまま参照されて子プロセスが落ちる、という構図です。

影響は2.4.30〜2.4.70と長く、mod_mdを読み込んでいる環境はほぼ全版が対象です。ただし落ちるのは子プロセスで、親プロセスが作り直すため、直ちに全停止するものではありません。それでも繰り返し送られればサービス品質は落ちます。証明書の自動取得をcertbotなど外部の仕組みで行っていてmod_mdを使っていないなら、md_module を外せば対象外になります。

CVE-2026-109163：mod_vhost_aliasの1バイト書き込み

CVE-2026-63292の修正後に残った不具合が、この1バイト書き込みです。

件名に「after CVE-2026-63292」とあるとおり、2.4.69で直したmod_vhost_aliasのスタックオーバーフロー（CVE-2026-63292）の修正に、境界の判定が1バイトずれる誤りが残っていました。修正コミット5566851は、サイズ判定の不等号を > から >= に改めた1行です。影響は2.4.69と2.4.70だけで、Apache評価はlowです。

Red HatはRHEL 6〜10のhttpdをすべてNot affectedとしています。RHEL系は63292を独自にバックポートしており、この誤りを含む上流の修正を取り込んでいないためと考えられ、上流の版番号だけでは判定できない例の1つです。一方、2.4.69へ追従したDebian 13（trixie）のセキュリティ更新やソースビルド、公式Dockerイメージの2.4.69は対象になります。VirtualDocumentRootでホスト名書式を使っていなければ攻撃経路はありません。

2.4.67で修正された11件：Apache評価とCISA-ADPが割れるCVEの境界

Apache公式のセキュリティ情報から、2.4.67で修正された11件を整理します。深刻度はApacheセキュリティチームの4段階評価、ADPはNVDに載るCISA-ADP（Authorized Data Publisher。UUID 134c704f-…）が付けたCVSS 3.1の基本値です。本表はNVDに掲載されたCISA-ADPの値を採用しています。NVDには、CVE-2026-23918やCVE-2026-28780のようにRed Hatが付けた値が併記されているものもあり、同じCVEでも提供者によってスコアが異なります。CVSSの読み方はCVSSv3とは？v3.1の計算式とスコアの目安を参照してください。

Apacheの評価とADPの数値は一致しません。ADPはネットワーク到達性などをCVSSの指標で表し、Apacheは独自の深刻度区分で評価します。評価の差を、ADPが常に最悪値を採るためだと一般化することはできません。だから「Apacheがlowだから後回し」も「ADPが9.8だから最優先」も単独では危険で、判断は後述の有効モジュールと構成で決めてください。

CVE-2026-23918：2.4.66だけに存在したHTTP/2の二重解放

Apacheの件名は「http2: double free and possible RCE on early reset」で、HTTP/2接続の早期リセット時に二重解放が起き、リモートコード実行の可能性があるとしています。影響版は2.4.66の1版だけです。報告は2025年12月10日、修正はr1930444で翌12月11日という経過以上の技術的詳細は公表されていません。

Red HatはRHEL 6〜10のhttpdとmod_http2をすべてNot affectedと判定しています。2.4.66を入れていたのは、上流版へ追従するDebianの更新やソースビルド、公式Dockerイメージの利用者です。自社が2.4.66を一度でも導入したかは、パッケージ管理のトランザクション履歴やデプロイ記録で確認します。後述のパッケージ変更履歴は修正内容の記録であり、その環境の導入履歴ではありません。

CVE-2026-33523：バックエンド経由のHTTPレスポンス分割と修正パッチの中身

件名は「multiple modules: HTTP response splitting forwarding malicious status line」です。バックエンドが返したステータス行に改行や制御文字が混じっていると、複数のモジュールがそれをそのままクライアントへ転送し、応答が分割されます。成立条件は「untrusted or compromised backend servers」、つまりApacheが中継する先のサーバを攻撃者が制御できることで、Red Hatはこの成立条件を理由に深刻度をModerateと評価しています。CISA-ADPのCVSS基本値は6.5です。中継の仕組みそのものはリバースプロキシの仕組みとフォワードプロキシとの違いで解説しています。

この1件で実務上いちばん効くのは、Red HatのCVEページでRHEL 6〜10のhttpdがFix deferred（修正保留）になっている点です。RHEL系を dnf upgrade しても、この脆弱性は残ります。外部のAPIや利用者が持ち込むサーバへProxyPassで中継している構成は、中継先の限定と、応答ヘッダに制御文字が無いかの検査で補ってください。

修正の実体を見ると、構成で補うべき範囲がはっきりします。2.4.x向けの修正コミットr1933360（trunkのr1933359を取り込み。件名「scan outgoing status line for newlines and controls」）は、modules/http/http_filters.c の validate_status_line() に次の数行を足しただけです。

/* 送出するステータス行(先頭の「NNN 」の後ろ)に改行・制御文字が無いか走査する */
if (len > 4 && *ap_scan_http_field_content(r->status_line + 4)) {
    r->status_line = NULL;   /* 不正な理由句は破棄してエラーにする */
    return APR_EGENERAL;
}

つまり対策は「中継してきたステータス行の理由句を検査して弾く」ことなので、Fix deferredのRHEL系で手当てするなら、同じ発想で中継先の応答を信頼しない（ステータス行を検査する前段を置く、信頼できるバックエンドにだけ中継する）のが筋です。素のリクエストやヘッダ本体ではなく「バックエンドが返すステータス行」が問題である点を外すと、対策がずれます。

CVE-2026-28780ほかAJP系4件：lowとADP 9.8の評価差

対象はmod_proxy_ajp系の4件で、Apacheの「low」とADP 9.8という評価の落差を確認します。

AJPの4件（CVE-2026-28780・33857・34032・34059）はいずれも、mod_proxy_ajpが悪意あるAJPサーバへ接続したときに成立します。CVE-2026-28780ではヒープバッファの末尾に攻撃者の値を4バイト書き込まれ、Apache評価はlowですがCISA-ADPは9.8 CRITICAL、Red Hatの自前評価もImportant/8.1です。CISA-ADPとRed HatではCVSSの攻撃条件の評価が異なります。ただし、この差だけでバックエンド侵害の前提を考慮したかどうかは断定できません。

裏を返すと、mod_proxy_ajpによるAJP中継を使っていなければ、この4件の攻撃経路は成立しません。中継している場合も、中継先のサーバ（代表例はTomcat）が攻撃者の制御下にあることが前提です。Tomcat側の脆弱性はApache Tomcatの脆弱性一覧【2026年10月】で追えます。AJPを使っていないのにproxy_ajpを読み込んでいるだけなら、この機会に外しておけば、以後の対応対象に含める必要はありません。Apache HTTP ServerからTomcatへHTTPで転送する設定と、AJPを使い続ける場合のsecretの設定はApacheとTomcatの違いで解説しています。

CVE-2026-24072・33006とmod_md系の権限昇格・認証の問題

ここでは.htaccessの権限昇格と、Digest・OCSPに関わる問題を扱います。

CVE-2026-24072は、ap_exprを解釈する複数のモジュールを通じて、.htaccessを書ける利用者がhttpd実行ユーザー権限でファイルを読める問題です。JVNは「mod_rewriteにおける権限昇格」と表記しています。利用者に.htaccessを書かせる共有ホスティングではテナント間の越境になります。同種の問題は2.4.68のCVE-2026-44119、2.4.69のCVE-2026-59797（mod_sslのSSLRequire）でも続けて修正されました。

CVE-2026-33006はmod_auth_digestへのタイミング攻撃によるDigest認証の回避で、Digest認証を使っていなければ該当しません。残るmod_md（CVE-2026-29168＝OCSP応答の無制限確保）・mod_dav_lock（CVE-2026-29169＝NULL参照でクラッシュ）・mod_authn_socache（CVE-2026-33007＝キャッシュ型フォワードプロキシでのクラッシュ）も、それぞれのモジュールを読み込んでいなければ成立しません。mod_mdは2.4.71でもCVE-2026-106023が直っており、同じモジュールで続けて修正が出ています。Apacheはmod_dav_lockについて「mod_davやmod_dav_fsからは使われず、既知の用途はSubversion 1.2.0未満のmod_dav_svnだけ」と書き、モジュールの削除も対策に挙げています。

2.4.68・2.4.69の追加修正と途中の版で止めてはいけない理由

2.4.68の13件と2.4.69の20件は、いずれも手前の版に影響します。そして2.4.69・2.4.70も、2.4.71の3件の影響範囲に入ります。途中の版で止める利点はありません。2.4.68・2.4.69の分から、対応判断に効くものだけ挙げます（ADPはNVDのCISA-ADP値）。

• CVE-2026-57941（2.4.69で修正、現在のApache公式勧告では2.4.17〜2.4.68が対象）：mod_http2の解放後使用。Apache評価moderate、ADP 9.8 CRITICAL。10月時点で未修正だったRHEL 9系のmod_http2は2026年11月11日のRHSA-2026:98981で修正されたが、Debian 12（bookworm、旧安定版）は2026年11月12日時点でも未修正。
• CVE-2026-49975（2.4.68で修正、2.4.17〜2.4.67）：HTTP/2のメモリ過大確保によるDoS。Apache評価moderate、ADP 7.5。NVDの参照にExploitタグ付きのPoCリポジトリが登録されている。
• CVE-2026-63292（2.4.69で修正）：mod_vhost_aliasのスタックオーバーフロー。ADP 7.5・Red Hat評価Important。VirtualDocumentRootでホスト名書式を使い、LimitRequestFieldSizeを既定より上げた構成で、長いHostヘッダによりDoSや任意コード実行の可能性。上流の修正には1バイトの誤りが残り、2.4.71でCVE-2026-109163として直された。
• CVE-2026-29167（2.4.68で修正）：mod_ldapのディレクトリ単位設定での解放後使用。Apache評価lowだが、ADPは9.8。
• CVE-2026-42356（2.4.69で修正、2.4.60〜2.4.68）：CGIディレクトリ内での内部リダイレクト先がCGIとして実行される限定的なRCE。Apache評価low、ADP 3.7。

このようにApacheの評価とADPの数値が大きく割れるものが混ざるため、「lowだから後回し」は危険です。CVE番号ごとの全件とApache・Red Hat・CISA-ADPの3者比較、ディストリ別のCVE単位の修正状況はJVN公表の影響範囲の記事に表で載せています。

自社環境の該当判定：版番号・有効モジュール・パッケージの3段確認

版番号が該当しても、モジュールを読み込んでいなければ攻撃は成立しません。逆に、版番号が古く見えても修正済みのことがあります。3段で順に確かめます。ここは脆弱性診断・セキュリティ診断でも最初に切り分ける順序で、自社の構成がどのCVEに実際にさらされているかを特定してから手を打つためのものです。

PATH上のApache実行ファイルの版と上流修正版2.4.71の比較

次のスクリプトは、httpd か apache2 の版表示から番号を取り出し、上流の修正版2.4.71と比べます。版番号の比較は文字列比較だと「2.4.9」と「2.4.71」の大小を誤るため、sort -V を使っています。10月版の本記事で2.4.69を基準にしていた場合は、FIXED の値を差し替えてください。

#!/bin/sh
# PATH上のApache実行ファイルの版を、上流修正版 2.4.71 と比較する
# 稼働中プロセスの実行ファイルと更新後の再起動は別途確認する
FIXED=2.4.71
BIN=$(command -v httpd || command -v apache2)
VER=$("$BIN" -v 2>/dev/null | sed -n 's#^Server version: Apache/\([0-9][0-9.]*\).*#\1#p')
echo "binary=$BIN version=$VER"
if [ -z "$VER" ]; then echo "版を取得できません"; exit 2; fi
if [ "$(printf '%s\n%s\n' "$FIXED" "$VER" | sort -V | head -n1)" = "$FIXED" ]; then
  echo "上流版としては $FIXED 以上"
else
  echo "上流版としては $FIXED 未満。ディストリのパッケージならバックポート状況を次段で確認"
fi

2026年11月12日時点で、公式Dockerイメージ httpd:2.4 は2.4.71に切り替わっています（Docker Hubのhttpd公式イメージで、2.4 と 2.4.71 のタグが同日に更新）。ソースビルドと公式イメージはこの版番号がそのまま答えになります。2026年10月24日の確認では、Ubuntu 24.04 のapache2パッケージが2.4.58系、AlmaLinux 9（RHEL 9系）のhttpdが2.4.62系でした。UbuntuとAlmaLinuxはディストリ版なので、3段目に進みます。

有効モジュールの確認とDebian系でapache2ctlを使う理由

今回のCVEに関わるモジュールが読み込まれているかを確認します。Debian・Ubuntu系で apache2 -M を直接実行すると、${APACHE_RUN_DIR} is not defined の警告と構文エラーで止まり一覧が出ません。出力が空なのを「該当モジュールなし」と読み違えないよう、環境変数を読み込む apache2ctl -M を使います。

# RHEL系・ソースビルド
httpd -M 2>/dev/null | grep -E 'http2|proxy_ajp|dav|ldap|auth_digest|md_module|vhost_alias|authn_socache|cgi'
# Debian・Ubuntu系
MODULES=$(apache2ctl -M) && printf '%s\n' "$MODULES" | grep -E 'http2|proxy_ajp|dav|ldap|auth_digest|md_module|vhost_alias|authn_socache|cgi'

2.4.71の3件に絞るなら、見るのは http2_module・md_module・vhost_alias_module の3つです。http2_module は読み込まれていても、Protocols ディレクティブで h2 を許可していなければHTTP/2で接続されません。設定ファイルを grep -R "Protocols" /etc/httpd /etc/apache2 2>/dev/null のように引いて、実際にh2を受けているかまで確かめると判断が締まります。

AlmaLinux 9（RHEL 9系）に標準のhttpdとmod_http2を導入すると、http2・cgid・dav系などが既定で読み込まれます。RHEL系は「入れただけで有効」になるモジュールが多い点を前提に、表で該当したモジュールが実際にloadされているかを突き合わせてください。

RHEL系はmod_http2が別パッケージで変更履歴も別になる点

RHEL 9系では、HTTP/2モジュールはhttpdではなく mod_http2 パッケージが提供します。変更履歴も別なので、httpdだけを調べる方法ではHTTP/2の修正を見落とすおそれがあります。導入済みの両パッケージの照合が必要です。導入済みパッケージの変更履歴からCVE番号を直接引き当てます。

rpm -q httpd mod_http2
rpm -q --changelog httpd | grep -oE 'CVE-2026-[0-9]+' | sort -u
rpm -q --changelog mod_http2 | grep -oE 'CVE-2026-[0-9]+' | sort -u

2026年10月24日に確認したAlmaLinux 9 の httpd-2.4.62-13.el9_8.9・mod_http2-2.0.26-6.el9_8.2 パッケージの変更履歴には、httpd側に24072・44119・63292など29件、mod_http2側に48913・49975・43951の3件のCVEが記録されていました。CVE-2026-33523はどちらにも含まれず（前述のFix deferredと整合）、CVE-2026-57941もmod_http2の履歴に無い状態でした。その後Red Hatは2026年11月11日のRHSA-2026:98981でmod_http2-2.0.26-7.el9_9.1を出し、57941と2.4.71のcritical 119618をまとめて修正しています。

2.4.71の3件と10月から残っていた57941に絞って、取り込み済みかを確かめるなら次のとおりです。何も表示されなければ、そのパッケージには該当CVEの修正記録がありません。

# RHEL・AlmaLinux系：mod_http2 に 119618 と 57941 の修正が入ったか
rpm -q mod_http2
rpm -q --changelog mod_http2 | grep -E 'CVE-2026-(119618|57941)'
# Debian・Ubuntu系：導入済み apache2 の変更履歴で 2.4.71 の3件を確認
zgrep -E 'CVE-2026-(119618|106023|109163)' /usr/share/doc/apache2/changelog.Debian.gz

ディストリ別の更新手順と2026年11月12日時点のパッケージ状況

RHEL・AlmaLinux系はhttpd一式とmod_系をまとめて更新

dnf upgrade httpd だけではmod_http2やmod_sslが取り残されることがあります。更新対象として指定するのは、導入済みのhttpd関連とmod_系のパッケージ一式です。このupgrade指定は導入済みパッケージの更新を対象にしますが、依存関係の解決に伴う追加インストールは起こり得ます。確定前にトランザクションの追加・更新対象を確認してください。

sudo dnf upgrade 'httpd*' 'mod_*'
sudo apachectl configtest && sudo systemctl restart httpd

Red HatのCVE-2026-119618のページでは、RHEL 9向けにRHSA-2026:98981（mod_http2-2.0.26-7.el9_9.1）、RHEL 10向けにRHSA-2026:98978（mod_http2-2.0.29-5.el10_3.1）が2026年11月11日付で出ています。RHEL 6〜8のhttpdは119618についてNot affectedです。ただしRHEL 8のmod_http2は、10月のCVE-2026-57941について2026年11月12日時点でもAffectedのままです。AlmaLinuxなどの再構築ディストリは同等の更新を追って配布するので、dnf upgrade 後に上の rpm -q --changelog で119618と57941が入ったかを確認してください。

RHEL 9系のmod_vhost_alias（CVE-2026-63292）は、2026年10月22日のRHSA-2026:88229でhttpd-2.4.62-13.el9_8.9として修正済みです。2.4.71で直ったmod_vhost_aliasの1バイト書き込み（CVE-2026-109163）は、Red HatがRHEL 6〜10のhttpdでNot affectedと判定しています。

Debian・Ubuntu系のapt更新と配布元別の修正状況

Debianは安定版でも、上流の版へ追従する方式で更新を配布しています。Debianのセキュリティトラッカーでは、2026年11月12日時点で2.4.71の3件がbookworm（12）・trixie（13）ともvulnerable（未修正）で、修正済みはunstable（sid）の2.4.71-1だけです。CVE-2026-57941は、trixieがtrixie-securityの2.4.69-1~deb13u1で修正済み、bookwormは2.4.68-1~deb12u1でも未修正のままです。HTTP/2を有効にしているDebianのサーバは、セキュリティ更新が出るまで後述の暫定対応を検討してください。

Ubuntuは版番号を据え置いて修正を取り込む方式で、24.04向けには2.4.58-1ubuntu8.17が提供され、公式CVE情報ではCVE-2026-57941・63292まで対応しています。版番号が2.4.58のままでも2.4.69相当の修正が入っている例です。一方で2.4.71の3件は、2026年11月12日の確認時点でUbuntuの公式CVE情報にまだ掲載が無く、修正状況を確認できていません。2.4.58はCVE-2026-119618の上流の影響範囲（2.4.55以降）に入る版番号なので、配布元の掲載を待つ間も、HTTP/2の扱いは先に決めておくのが安全です。

dpkg-query -W apache2
zgrep -oE 'CVE-2026-[0-9]+' /usr/share/doc/apache2/changelog.Debian.gz | sort -u
sudo apt update && sudo apt install --only-upgrade apache2
sudo apache2ctl configtest && sudo systemctl restart apache2

apt changelog apache2 は変更履歴を取得するコマンドで、導入済み版を明示して確認することもできます。ここでは取得対象の取り違えを避けるため、導入済みパッケージに付属する履歴を使います。手元の changelog.Debian.gz を見てください。

ソースビルドの更新と公式Dockerイメージのタグ追従状況の確認

ソースビルドは公式ダウンロードページから2.4.71を取得し、署名を検証してから入れ替えます。2.4.71の公式告知は、APRとAPR-Utilの1.5系以上を前提とし、一部の機能には1.6系が要るとしています。公式Dockerイメージ httpd:2.4 は、2026年11月12日に2.4.71へ切り替わりました（10月24日の確認時は2.4.69）。タグを固定していても、ローカルに古いレイヤが残っていれば古いままなので、docker pull httpd:2.4 のあと docker run --rm httpd:2.4 httpd -v で取得したイメージ内の版を確認してください。既存コンテナはpullだけでは更新されないため、設定と永続データを引き継いで新しいイメージから再作成します。

更新後のconfigtestと2.4.69・2.4.71で変わる挙動の確認

2.4.69の変更履歴には、セキュリティ修正のほかに動作が変わる項目があります。mod_mdのMDServerStatusは既定で無効になり、mod_auth_digestではAuthNameを式で指定した場合の互換性修正に加え、RFC 2069方式のサポート削除も行われました。旧方式を使うクライアントは、更新前に認証の互換性を確認してください。MDServerStatusで証明書状態を監視している環境は、更新前に監視側を見直してください。

2.4.69から直接2.4.71へ上げる場合は、間の2.4.70と2.4.71の変更も一緒に入ります。2.4.71の変更履歴では、mod_remoteipのRemoteIPTrustedProxyList・RemoteIPInternalProxyListが設定したバーチャルホストに適用されるよう改められ、メインサーバとバーチャルホストの両方に書いた場合は警告が出るようになりました。プロキシやロードバランサの背後でクライアントIPを取り直している構成は、更新後にアクセスログのIPが想定どおりかを見てください。mod_mdではMDHttpProxyとMDCACertificateFileをMDomainごとに指定できるようになっています。2.4.70ではmod_cgidの環境変数・URI・引数の上限が引き上げられました。更新後は構文チェック、再起動、プロセスの起動時刻の確認までを一続きで行い、古いバイナリのまま動き続けていないことを確かめます。

PoC公開・悪用状況の確認と、すぐ更新できないサーバの暫定対応

KEV未掲載とPoC公開済みのCVE-2026-49975の扱い

2026年11月10日版のCISA KEVに、2026年に公表されたhttpdのCVEは載っていません。KEVに載っているApache HTTP Serverの脆弱性は、2021年のパストラバーサルCVE-2021-41773・CVE-2021-42013や2024年のCVE-2024-38475などです。ただしKEV未掲載だけでは悪用の有無を判断できず、CVE-2026-49975はHTTP/2を有効にしたサーバへ小さなリクエストで大量のメモリ確保を起こすPoCが、NVDの参照に登録されたリポジトリで公開されています。2.4.71のCVE-2026-119618も、修正差分が1行で公開されている以上、攻撃手法の解析は難しくありません。インターネットに面したHTTP/2有効のサーバは、この2件を基準に更新期限を決めてください。KEVを起点に適用の優先度を決め、aptやdnfで定期適用する運用の組み立てはパッチ管理とは：KEVで優先度を決めて自動適用する手順で解説しています。

未使用モジュールの無効化とHTTP/2停止による更新前の攻撃面の縮小

検証や再起動の都合ですぐ更新できない場合は、使っていないモジュールを外して攻撃面を減らします。HTTP/2を止めればmod_http2の各CVE（23918・49975・57941・119618）は成立しなくなりますが、HTTP/1.1へ縮退するため、表示速度への影響を確かめてから入れてください。

# Debian・Ubuntu系：HTTP/2を無効化
sudo a2dismod http2 && sudo apache2ctl configtest && sudo systemctl restart apache2
# RHEL系：10-h2.conf の LoadModule をコメントアウト
sudo sed -i 's/^LoadModule http2_module/#LoadModule http2_module/' /etc/httpd/conf.modules.d/10-h2.conf
sudo apachectl configtest && sudo systemctl restart httpd

モジュールごと外せない事情があるなら、Protocols http/1.1 を明示してh2を受けない設定にする方法もあります。ただし設定の書き漏れでh2が残るとそこが穴になるため、変更後に curl --http2 -sI https://対象ホスト/ などで応答がHTTP/1.1になったことを確かめてください。

AJPを使っていなければproxy_ajp、WebDAVを使っていなければdav系、Digest認証を使っていなければauth_digest、ACMEの自動取得を使っていなければmd、VirtualDocumentRootを使っていなければvhost_aliasも同様に外します。.htaccess経由の権限昇格はWAFでは防げないため、共有環境で.htaccessを無効化する場合は、対象ディレクトリの AllowOverride None と AllowOverrideList None を確認します。利用を続ける場合は、各CVEで問題となる式やディレクティブを許可対象から除外してください。どれも恒久対策ではありません。更新が遅れがちな体制を見直すなら、一創の脆弱性診断・セキュリティ診断で、該当CVEの切り分けからパッチ適用の手順化・検証環境の整備まで支援しています。もう一方の主要Webサーバの動向はNGINX Rift（CVE-2026-42945）の影響判定も参考になります。

よくある質問

2.4.67〜2.4.71への更新先と、構成・配布元による影響判定の疑問に答えます。

2.4.69・2.4.70・2.4.71のどれに上げるべきですか？

2.4.71です。2.4.69と2.4.70は、mod_http2のcritical CVE-2026-119618（2.4.55〜2.4.70）とmod_mdのCVE-2026-106023（2.4.30〜2.4.70）の影響範囲に入り、mod_vhost_aliasのCVE-2026-109163も2.4.69・2.4.70だけが対象です。2.4.68以前ならさらに2.4.69で直った20件も残ります。2.4.70はCVE付きの修正を含まないため、経由する利点はありません。ディストリのパッケージを使っている場合は、版番号ではなく配布元が2.4.71相当の修正をいつ出すかを追ってください。

CVE-2026-33523はどの構成なら影響を受けますか？

2.4.0〜2.4.66で、Apacheがリバースプロキシとして中継する先のバックエンドを攻撃者が制御できる構成です。自社管理の内部アプリにだけ中継しているなら、実害の前提は満たしにくくなります。RHEL系はRed Hatが修正を保留（Fix deferred）しているため、dnf upgrade しても残る点に注意し、中継先の限定と応答ステータス行の検査で補ってください。

Apacheの評価がlowなのにADPが9.8のCVEは、本当に急ぐべきですか？

構成次第です。CVE-2026-28780（AJP、Apache low／ADP 9.8）は、mod_proxy_ajpで悪意あるAJPサーバへ接続する場合にだけ成立します。AJP中継がなければ、この攻撃経路は成立しません。自社管理のバックエンドでも侵害される可能性があるため、管理主体だけで緊急性を下げず、侵害兆候とアクセス制御を確認してください。逆にADPが低くても、該当モジュールを公開面で使っていれば優先度は上がります。2.4.71の3件のようにNVDの評価がまだ付いていない段階でも、有効モジュールと到達経路で判断できます。

ディストリの版が2.4.58や2.4.62のままですが、未対応ですか？

必ずしもそうではありません。Ubuntuは2.4.58、RHEL 9系は2.4.62の版番号を据え置いて修正を取り込みます。導入済みパッケージの変更履歴でCVE番号を確かめ、RHEL系ではmod_http2の変更履歴も見てください。RHEL 9系はmod_http2-2.0.26-7.el9_9.1以降で119618と57941が入ります。Debianは2026年11月12日時点で2.4.71の3件が未修正、Ubuntuは公式CVE情報への掲載待ちなので、最終判断は配布元のCVEページで行います。

Apache TomcatとApache HTTP Serverは同じものですか？

別製品です。本記事の対象はWebサーバのApache HTTP Server（httpd）で、JavaサーブレットコンテナのApache Tomcatとは脆弱性も修正版も異なります。両者をAJPでつなぐ場合のmod_proxy_ajpが接点で、Tomcat側の修正は別途確認が必要です。CVEやNVD・ADPの関係そのものはCVE（共通脆弱性識別子）とはで整理しています。

関連記事

• JVNが公表したApache HTTP Server 2.4系の複数脆弱性：2.4.68・2.4.69の33件の影響範囲とディストリ別の修正状況：CVE別の3者評価と修正状況の全表
• CVE-2021-41773・CVE-2021-42013とは｜Apache 2.4.49・2.4.50のRCEとログに来る攻撃文字列の読み方：KEV掲載の過去の重大脆弱性
• Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順：AJP中継先のTomcat側の修正
• NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身｜1.30.6までの対応：もう一方の主要Webサーバの動向
• リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説：CVE-2026-33523の前提になる中継構成
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：更新期限の決め方と定期適用
• CVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説：Apache評価とADPの数値が割れる理由