Apache Tomcat 脆弱性（2026 年 10 月）｜影響条件と更新判断

はじめに

Apache Software Foundation（ASF）は 2026 年 10 月 20 日、Apache Tomcat の脆弱性 8 件を公表しました。修正版の 11.0.27、10.1.61、9.0.123 は、公表に先立つ 10 月 12 日にリリースされています。

今回は CVSS 9.1（CRITICAL）と評価された脆弱性が 3 件含まれる一方、8 件すべてが 3 系列に共通するわけではありません。影響の有無は、稼働中のバージョンと、JNDIRealm、HTTP/2、AJP などの設定によって大きく変わります。本記事では、自社の Tomcat 環境がどの脆弱性の対象になるかを判断し、更新と確認作業につなげるための情報を整理します。

結論として、サポート中の 3 系列はいずれも 11.0.27、10.1.61、9.0.123 への更新で 8 件すべてに対処できます。優先度は CVSS の数値だけで決めず、JNDIRealm の認証方式、HTTP/2 と非同期 Servlet の利用、Tomcat 11 系での AJP 利用の有無を確認したうえで判断することを推奨します。

Apache Tomcat 脆弱性 8 件の修正版と影響範囲

修正版は系列ごとに 1 つです。8 件のうち CVE-2026-103119 は Tomcat 11 系のみ、CVE-2026-80353 は Tomcat 9 系のみが対象で、ほかの CVE も系列ごとに影響の開始バージョンが異なります。

Tomcat 10.0.x、8.5.x などのサポート終了済み系列には修正版が提供されません。CVE Record では、CVE-2026-101296 と CVE-2026-74049 について 8.5.0〜8.5.100 と 7.0.0〜7.0.109 も影響を受けると記載されています。サポート終了済み系列を利用している場合は、サポート中の系列への移行が必要です。

8 件の概要と深刻度

Apache は自身の基準で 3 件を Important、5 件を Low と評価しています。CVSS 9.1 は、CVE Record に CISA の ADP（Authorized Data Publisher）が追加した評価です。評価主体と CVSS のバージョンが異なる点に注意してください。

CVSS の「記載なし」は、2026 年 10 月 22 日時点の CVE Record に CVSS スコアが含まれていないことを示します。NVD などで後日スコアが追加される可能性があります。

国内では、JVN が 2026 年 10 月 21 日に JVNVU#93110597 として 8 件をまとめて公開しています。影響バージョンの詳細は、Apache の Advisory を参照するよう案内されています。

系列ごとの影響バージョン

次の表は Apache の Security Advisory に記載された影響範囲です。稼働中のバージョンが範囲に含まれるかを CVE ごとに照合します。

CVE-2026-101356 の影響範囲は比較的新しいバージョンに限られます。たとえば 10.1.54 以前はこの CVE の対象外ですが、CVE-2026-101296 など他の CVE の対象であり、過去に公表された脆弱性も未修正のままになっている可能性があります。1 件が対象外であることを、更新不要の根拠にしないでください。

影響に関係する機能と確認事項

CVSS 9.1 と実際の悪用状況

CISA-ADP の CVSS は、脆弱な設定が存在することを前提にした基本評価です。たとえば CVE-2026-101296 の CVSS 4.0 ベクターでは攻撃要件（AT）が「Present」とされており、JNDIRealm を使っていない環境では成立しません。CVSS が高いことと、自社環境で攻撃が成立することは分けて判断してください。

悪用状況について、2026 年 10 月 22 日時点で次の公式情報を確認しました。

• CISA KEV カタログ（2026 年 10 月 21 日公開版）に、今回の 8 件は登録されていません。
• CVE Record の CISA-ADP による SSVC 評価では、Important の 3 件の「Exploitation」が「none」とされています（10 月 20 日時点の評価）。
• Apache の Security Advisory に、実際の悪用に関する記載はありません。

確認できた公式情報の範囲では実悪用は確認できませんが、これは悪用されていないことを保証するものではありません。修正内容は公開リポジトリのコミットとして参照できるため、今後の状況は KEV や各ベンダーの情報で継続的に確認することを推奨します。

特に注意したい 3 件の脆弱性

Apache が Important と評価した 3 件は、いずれも特定の機能や設定を使っている場合に影響が生じます。ここでは成立条件と、対象かどうかを見分けるポイントを解説します。

CVE-2026-101296: JNDIRealm の認証回避

JNDIRealm は、Tomcat が LDAP ディレクトリ（Active Directory を含む）を参照して、ユーザー名、パスワード、ロールを検証するための Realm です。Web アプリケーションの BASIC 認証や FORM 認証などで、認証情報の照合先として使われます。

参考: Apache Tomcat 9.x vulnerabilities
“allowed attackers to authenticate without providing the correct password.”
（攻撃者が正しいパスワードを提示せずに認証できた。）
https://tomcat.apache.org/security-9

Advisory が示す成立条件は、JNDIRealm が「GSSAPI 以外の SASL 認証機構」で構成されている場合です。SASL は LDAP などで使われる認証の枠組みで、GSSAPI（Kerberos）はその機構の 1 つです。LDAP 接続時の認証方式は、JNDIRealm の authentication 属性で指定します。

参考: Apache Tomcat 9 Configuration Reference（The Realm Component）
“none”, “simple”, “strong” or a provider specific definition can be used.
（”none”、”simple”、”strong”、またはプロバイダー固有の定義を指定できる。）
https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html

authentication を指定しない場合は、JNDI プロバイダーの既定値が使われます。また、修正版の changelog（Tomcat 9 changelog）では、利用者が入力した名前とパスワードで bind して認証する際に、ドキュメントどおり常に simple bind を使うよう修正したと説明されています。このため、authentication 属性の値だけで対象外と断定することはできません。

LDAP を使う Tomcat 環境がすべて影響を受けるわけではありませんが、対象外と判断できるのは JNDIRealm を使っていない場合に限られます。次のように切り分けます。

JNDIRealm を使っていない

Tomcat の JNDIRealm を使わず、アプリケーションやフレームワーク側で LDAP 認証を実装している場合、この CVE の Tomcat 側の成立条件には該当しません。アプリ側の LDAP 実装は別途の評価対象です。

JNDIRealm で非 GSSAPI の SASL 機構を使っている

Advisory が示す成立条件に該当します。影響対象として、最優先で修正版へ更新することを推奨します。

JNDIRealm を使っているが、実際の認証方式が不明

authentication の値に加え、利用者の認証で bind を行うか（userPassword を指定していない場合は、利用者の DN とパスワードで bind します）、使用している JNDI プロバイダーが既定でどの方式を使うかを確認します。実際の bind 方式を判断できない場合は、対象外と断定せず、影響を受ける前提で更新を優先してください。

設定は主に $CATALINA_BASE/conf/server.xml または各アプリの context.xml の <Realm className="org.apache.catalina.realm.JNDIRealm" ...> にあります。LockOutRealm や CombinedRealm の内側に入れ子で定義されている場合もあるため、Realm 要素をすべて確認してください。

更新後は、正しいパスワードでログインできることに加え、誤ったパスワードでログインが拒否されることをテスト用アカウントで確認します。認証回避の脆弱性では、正常系だけの確認では修正の効果を判断できません。

なお、JNDIRealm を使っていないためこの CVE が対象外と判断できても、HTTP/2 や JSTL など他の CVE の影響まで否定できるわけではありません。

CVE-2026-101356: HTTP/2 のリクエスト・レスポンス混線

HTTP/2 で非同期 Servlet を処理する際、オブジェクトの再利用（リサイクル）処理に誤りがあり、エラー発生後に異なる利用者間でリクエストやレスポンスが混線する可能性がある脆弱性です。

参考: Apache Tomcat 10.x vulnerabilities
“can trigger request and/or response mix-up between users.”
（利用者間でリクエストやレスポンスの混線を引き起こす可能性がある。）
https://tomcat.apache.org/security-10

Tomcat は性能のため、リクエストやレスポンスを表す内部オブジェクトを使い回します。使い終わったオブジェクトの状態が正しく初期化されないまま次の処理に渡ると、別の利用者のデータが見えるおそれがあります。HTTP/2 は 1 つの接続上で複数のストリームを並行処理し、非同期 Servlet は処理スレッドとリクエストのライフサイクルを切り離すため、エラー時の後始末が複雑になります。今回の問題は、この 2 つが重なる条件で発生します。

影響が生じると、ある利用者向けの応答が別の利用者に返るなど、情報漏えいにつながる可能性があります。ただし公式情報が示す条件は、HTTP/2、非同期 Servlet、処理中のエラーの組み合わせです。HTTP/2 を有効にしているだけで必ず混線が起きるわけではありません。

HTTP/2 は、HTTP Connector の内側に <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> を入れ子にして有効化します。この要素がなければ、その Connector は HTTP/2 を処理しません。

リバースプロキシやロードバランサーが前段にある場合は、クライアントとプロキシの間のプロトコルではなく、プロキシから Tomcat への接続で HTTP/2 が使われているかを確認します。クライアント側が HTTP/2 でも、プロキシから Tomcat へ HTTP/1.1 や AJP で中継していれば、その経路では Tomcat の HTTP/2 処理は使われません。一方、プロキシから Tomcat へ HTTP/2（h2c を含む）で接続する構成や、監視・社内システムがプロキシを経由せず Tomcat に直接接続する経路がある場合は確認対象になります。

非同期 Servlet は、アプリケーションやフレームワークの実装によって利用有無が決まります。インフラ側の設定だけでは判断できないため、アプリケーション担当者に確認することを推奨します。判断できない場合は、影響を受ける前提で更新を優先します。

CVE-2026-103119: AJP のレスポンス混線（Tomcat 11 系のみ）

AJP（Apache JServ Protocol）は、Apache HTTP Server の mod_proxy_ajp や mod_jk などの前段サーバーと Tomcat を接続するためのプロトコルです。前段サーバーが静的コンテンツや TLS を処理し、動的な処理を Tomcat に中継する構成で使われます。

今回の問題はバッファーのアンダーリードで、大きなノンブロッキング書き込みを行った際に、レスポンス本文が同じ接続で受け付けた次のリクエストとの間で分割される可能性があります。

参考: Apache Tomcat 11.x vulnerabilities
“possibly leakage of data from the first response to the second.”
（最初のレスポンスのデータが 2 番目に漏えいする可能性がある。）
https://tomcat.apache.org/security-11

Advisory は、2 番目のリクエストが失敗する可能性が最も高く、データ漏えいは起こり得る結果の 1 つとしています。前段サーバーは複数の利用者のリクエストを同じ AJP 接続で順に送るため、漏えいが起きた場合は別の利用者へ応答の一部が渡る可能性があります。

影響を受けるのは Tomcat 11.0.0-M25〜11.0.26 のみで、Tomcat 9 系と 10 系は対象外です。確認は、server.xml に protocol="AJP/1.3" の Connector が有効な状態で定義されているか、前段サーバーの設定で AJP による中継を行っているかの 2 点です。Connector がコメントアウトされている場合や、前段サーバーから HTTP で中継している場合は該当しません。

残る 5 件の優先度の考え方

残る 5 件は Apache の評価が Low ですが、該当する機能を使う環境では運用上の重要度が変わります。

CVE-2026-74048

FIPS モードを要件とする環境では、要件を満たさないまま運用が続く問題になります。修正版の changelog（Tomcat 11 changelog）では、FIPS が要求されているのに利用できない場合、OpenSSLLifecycleListener が AprLifecycleListener と同様に Error を発生させるよう修正したと説明されています。これまで FIPS の有効化に失敗したまま稼働していた環境では、更新後に起動時のエラーとして顕在化する可能性があります。更新前に起動ログで FIPS 有効化のエラーが出ていないかを確認してください。

CVE-2026-74049

リダイレクト後に続く処理（データ更新やログ出力など）が実行される可能性があります。リダイレクトをアクセス制御の代わりに使っている JSP がある場合は影響が大きくなります。

CVE-2026-88041

HTTP/2 の trailer 情報が後続のリクエストへ混入する問題で、確認対象は CVE-2026-101356 と同じ HTTP/2 の利用経路です。

CVE-2026-93446

主な影響は TLS 1.3 接続の断続的な失敗で、可用性の問題です。Tomcat で TLS を終端していない構成では該当しません。

CVE-2026-80353

以前の CVE-2026-65183 の修正が NIO Connector のみで、APR / Native Connector が未対応だった問題です。悪用にはローカルユーザーの存在が前提となります。

自社環境での Tomcat 脆弱性の影響確認方法

影響判定は、バージョンの照合から始め、設定と利用状況で優先度を決める順に進めます。次の手順は Apache の公式資料に基づく確認例で、筆者の環境で実施した結果ではありません。

$CATALINA_HOME/bin/version.sh

%CATALINA_HOME%\bin\version.bat

組み込み Tomcat、OS パッケージ、製品同梱版の判定

Apache 公式バイナリ以外の Tomcat は、バージョンの確認方法と更新経路が異なります。

組み込み Tomcat（Spring Boot など）

アプリケーションに同梱された tomcat-embed-core などのライブラリのバージョンで判定します。server.xml は使われず、HTTP/2 や Connector の設定はアプリケーションの設定やコードで行われます。更新はアプリケーションの依存関係を変更して再ビルドする必要があり、フレームワークの対応版を確認したうえで開発チームと調整します。

OS パッケージ

ディストリビューションが修正をバックポートし、Apache の修正版とは異なるバージョン番号で提供する場合があります。バージョン番号だけで判定せず、ディストリビューションのセキュリティアドバイザリで CVE ごとの対応状況を確認します。

商用製品に同梱された Tomcat

製品ベンダーが検証済みの更新を提供する前に Tomcat 単体を差し替えると、サポート対象外になる場合があります。製品ベンダーのアドバイザリと手順に従います。

修正版への更新と適用後の確認

今回の修正版は同じ系列内のバージョンアップのため、系列をまたぐ移行は不要です。Apache はバイナリパッチを提供しておらず、修正版のバイナリへの置き換えが基本となります。

更新時の確認ポイント

• 更新前に conf ディレクトリ、setenv.sh / setenv.bat、デプロイ済みアプリケーション、lib に追加したライブラリをバックアップします。
• Tomcat の changelog で、現行版から修正版までの変更点を確認します。今回の修正版にも、HTTP/2 や TLS ハンドシェイクに関する不具合修正が含まれています。
• テスト環境で、アプリケーションの主要機能と、利用している認証、HTTP/2、TLS、AJP の通信を確認してから本番へ適用することを推奨します。
• 冗長構成では、ロードバランサーから 1 台ずつ切り離して更新し、セッションの引き継ぎ方式に応じて切り替え時の影響を確認します。
• 切り戻しに備え、旧バージョンの CATALINA_HOME を残し、切り戻しの判断基準と手順を事前に決めておきます。ただし旧バージョンへ戻すと脆弱な状態に戻る点に注意してください。

対策完了の判定基準

更新作業が終わったことと、修正版が稼働して対策が完了したことは別です。次の 3 点がそろった時点で完了と判断します。

稼働バージョン

再起動後の起動ログで、Server version number が修正版以上であることを確認します。

全インスタンスへの適用

洗い出したすべてのインスタンス、待機系、検証環境、組み込み Tomcat を使うアプリケーションに適用されていることを確認します。

利用機能の動作

JNDIRealm の正常・異常の両方の認証、HTTP/2 と TLS 1.3 の接続、前段サーバーからの AJP 通信、FIPS 有効化のログなど、利用している機能に応じて動作を確認します。

応答の混線や認証回避は、正常なリクエストやログインと同じ形でアクセスログに記録される可能性があります。通常のアクセスログに異常がないことだけで、悪用がなかったとは断定できません。不審な点がある場合は、アプリケーションログや認証ログと突き合わせて調査してください。

Tomcat 9.0.123 とサポート終了への対応

Tomcat 9.0.x を利用している場合、今回の 8 件は 9.0.123 への更新で対処できます。これとは別に、9.0.x のサポート終了が予定されています。

参考: End of support for Apache Tomcat 9.0.x
“support for Apache Tomcat 9.0.x will end on 31 March 2027.”
（Apache Tomcat 9.0.x のサポートは 2027 年 3 月 31 日に終了する。）
https://tomcat.apache.org/tomcat-9.0.x-eos.html

同ページによると、9.0.x のサポート終了直前に後継の 9.1.x 系列がリリースされ、2030 年 12 月 31 日まで継続する予定です。9.0.x との差異は小さいとされていますが、APR / Native Connector が提供されず、Tomcat Native 1.3.x もサポートされません。APR Connector を使っている場合は、NIO Connector への移行が推奨されています。

Apache は 9.1.x にとどまらず、より新しい系列への移行も検討するよう勧めています。ただし Tomcat 10 以降はパッケージ名が javax.* から jakarta.* に変わるため、アプリケーションの改修や検証が必要です。今回の緊急対応は 9.0.123 への更新とし、系列の移行はサポート終了への対応として別途計画することを推奨します。

Tomcat では短い間隔で脆弱性の修正が続いており、2026 年 8 月には EncryptInterceptor の脆弱性が CISA KEV に追加されています。継続的な確認の参考として、Tomcat の EncryptInterceptor 脆弱性（CVE-2026-34486）の解説記事もあわせてご覧ください。

更新できない場合の暫定対策

Apache の Security Advisory には、今回の 8 件に対する更新以外の回避策は記載されていません。次の対策は、該当機能の利用を止めて影響範囲を狭めるための編集上の整理です。恒久対策は修正版への更新であり、WAF やアクセス制限だけで 8 件すべてに対応することはできません。

AJP を利用している Tomcat 11 系で更新までの期間が長くなる場合は、前段サーバーからの中継を HTTP に切り替えることも選択肢になります。ただし構成変更を伴うため、更新作業と同程度の検証が必要です。暫定対策を実施した場合も、更新の予定日を決めておくことを推奨します。

まとめ

2026 年 10 月公表の Apache Tomcat 脆弱性 8 件は、11.0.27、10.1.61、9.0.123 への更新で対処できます。CVSS 9.1 の 3 件も、影響は JNDIRealm の認証方式、HTTP/2 と非同期処理、Tomcat 11 系の AJP といった条件に左右されます。バージョンと設定の両面から影響を判定し、優先度を付けて更新することが重要です。

• 修正版はすべての 8 件に対応し、系列をまたぐ移行は不要です。
• CVSS 9.1 は CISA-ADP の評価で、Apache の評価は Important です。
• JNDIRealm を使う環境は、実際の bind 方式を確認してから判断します。
• HTTP/2 の混線は、Tomcat が HTTP/2 を直接処理する経路で確認します。
• AJP のレスポンス混線は Tomcat 11 系のみが対象です。
• 完了判定は、起動ログの稼働バージョンと全インスタンスへの適用で行います。
• Tomcat 9.0.x のサポート終了対応は、今回の更新とは別に計画します。

以上、最後までお読みいただきありがとうございました。