Apache Tomcatで認証回避と通信混在の脆弱性！9系から11系まで更新判断

Apache Tomcatの9系・10.1系・11系を運用している場合は、単に「Tomcatに8件の脆弱性」と捉えるのではなく、利用中の系統、AJPやHTTP/2の使用状況、JNDIRealmの認証方式を照合する必要があります。Apache Software Foundationは2026年10月20日、複数の脆弱性を公開しました。JVNも10月21日に国内向けの注意喚起を掲載しています。修正版は11.0.27、10.1.61、9.0.123です。

今回の問題には、特定条件で別の利用者の応答データが混ざる可能性、パスワードが正しくなくても認証が成立し得る設定依存の問題、FIPSモードの有効化失敗を見逃す問題などが含まれます。一方で、すべての脆弱性が全系統・全構成に当てはまるわけではありません。本稿では一次資料の公表内容と、Web運用者が行うべき確認手順を分けて整理します。情報確認日時は2026年10月21日13時台（日本時間）です。

最初に確認したい結論

• Tomcat 11は11.0.27、10.1系は10.1.61、9系は9.0.123への更新を基本方針にする
• 11系でAJPコネクターを使う環境はCVE-2026-103119を優先して確認する
• HTTP/2と非同期処理を使うWebアプリはCVE-2026-101356の影響範囲を確認する
• JNDIRealmでSASLを使う構成はCVE-2026-101296の条件を照合する
• 更新後は起動確認だけで終わらせず、認証・HTTP/2・AJP・TLS・アプリ固有の回帰試験を行う

Apacheの各セキュリティページでは、CVE-2026-103119、CVE-2026-101356、CVE-2026-101296をImportant、該当するその他の問題をLowとして扱っています。これはApacheによる評価であり、CVSSスコアへの置き換えではありません。また、公式ページに攻撃観測の説明は見当たりませんが、それだけで悪用がないとは断定できないため、利用状況とログを別途確認するのが安全です。

8件を系統と条件で切り分ける

Tomcat 11だけに影響するAJP応答の混在

CVE-2026-103119は、Tomcat 11.0.0-M25から11.0.26までのAJP実装に関する問題です。Apacheの説明では、ノンブロッキング方式で大きな応答を書き込むと、応答本文が現在のリクエストと次のリクエストにまたがって送られる可能性があります。結果として、ある利用者向けのデータが別の利用者の応答へ含まれるおそれがあります。Tomcat 10.1系と9系はこのCVEの対象として記載されていません。

AJPポートをインターネットへ直接公開していなくても、フロントのWebサーバーとTomcatの接続にAJPを使っていれば、構成上の関連は残ります。確認ではserver.xmlのConnectorだけでなく、Apache HTTP Serverのmod_proxy_ajpやmod_jk、コンテナ環境のテンプレート、古い構成ファイルの継承も対象にします。AJPを使用していないなら、その事実を設定と稼働中ポートの両方で確認すると判断記録が明確になります。

HTTP/2の非同期処理後に応答が混ざる可能性

CVE-2026-101356はHTTP/2リクエスト処理の問題で、11.0.22から11.0.26、10.1.55から10.1.60、9.0.118から9.0.122が対象です。非同期処理中のエラーを契機としてリクエストと応答の対応が崩れ、別のリクエストへ誤った応答が返る可能性が示されています。影響範囲が比較的新しいリリースに限定されるため、古い版がこのCVEだけを理由に安全になるわけではありません。古い版には別の既知脆弱性やサポート上の問題が残り得ます。

CDNやリバースプロキシで外部通信をHTTP/1.1へ変換している構成でも、プロキシからバックエンドTomcatまでHTTP/2を使っている可能性があります。ロードバランサー、Ingress、サービスメッシュを含め、どの区間でHTTP/2が終端されるかを確認してください。アプリ側ではServletのAsyncContext、ストリーミング応答、タイムアウトや例外発生時の挙動が試験対象になります。

JNDIRealmの特定SASL構成で認証が成立する問題

CVE-2026-101296は、JNDIRealmがGSSAPI以外のSASL認証を利用する場合に、バインド資格情報の検証が失敗しても認証を許可し得る問題です。対象は11.0.0-M1から11.0.26、10.1.0-M1から10.1.60、9.0.0.M1から9.0.122です。LDAPを使っているというだけで直ちに同じ条件になるわけではなく、TomcatのRealm種類、authentication設定、SASLの仕組みまで確認する必要があります。

特に注意したいのは、認証基盤の疎通確認だけでは問題を見つけにくい点です。正しいパスワードでログインできる試験に加え、誤ったパスワードが確実に拒否される負の試験を実施してください。管理画面、会員画面、API、バッチ用アカウントなど、同じRealmを使う入口を洗い出すことも重要です。

そのほかの低重要度問題

一次資料では、該当する系統に応じて次の5件も公開されています。

• CVE-2026-93446：TLS 1.3接続が断続的に失敗する可能性
• CVE-2026-88041：HTTP/2のトレーラーヘッダーが別リクエストへ残る可能性
• CVE-2026-74049：JSTLの<c:redirect>後もページ処理が継続する問題
• CVE-2026-74048：FIPSモード有効化に失敗してもJSSEの非FIPS構成で処理を継続し得る問題
• CVE-2026-80353：APRコネクターのUnix Domain Socket作成時に権限変更の競合が起こり得る問題

CVE-2026-80353はTomcat 9.0.47から9.0.122が対象で、10.1系と11系の該当リストには含まれません。ほかの4件も開始バージョンが系統ごとに異なります。したがって、CVE一覧だけを資産台帳へ貼り付けるのではなく、利用版と公式ページの影響範囲を突き合わせてください。詳細な対象範囲は、Apache Tomcat 11 Security、Apache Tomcat 10 Security、Apache Tomcat 9 Securityで確認できます。

公表日と修正版の日付を分けて読む

Apacheのページでは修正版のリリース日が2026年10月12日、各脆弱性の公表日が10月20日と示されています。これは、修正版が先に提供され、その後に詳細が公表された形です。本記事の構造化データでは公表日を2026年10月20日として扱います。記事の掲載日や、JVNが注意喚起を掲載した10月21日とは別の日時です。

運用記録には少なくとも「ベンダー公表日」「社内確認日」「更新実施日」を別欄で残すと、後から対応速度や判断根拠を検証できます。公表前に修正版へ更新済みだった場合も、対象構成だったか、更新版が実際に稼働しているかを確認して完了とします。

Web運用者が行う確認と更新の順序

1 実際に動くバージョンと系統を確定する

パッケージ管理画面やリポジトリの宣言だけでなく、稼働プロセスが読み込むTomcatのバージョンを確認します。WARを載せた共有Tomcat、アプリへ組み込んだTomcat、CI/CDのビルドイメージ、障害時に起動する待機系が別々の版を持つことがあります。コンテナではタグだけで判断せず、イメージダイジェストと内部のバージョンを記録してください。

2 影響条件を設定値から確認する

AJP Connector、HTTP/2 UpgradeProtocol、JNDIRealm、SASL、FIPS設定、Unix Domain Socket、JSTL利用箇所を棚卸しします。設定ファイルだけでなく、環境変数や起動オプション、KubernetesのConfigMapやSecret、プロキシ側の設定も対象です。ここで「使っていない」と確認できた条件は、根拠となるファイルやコマンド結果をチケットへ添付します。

3 更新前にロールバック条件を決める

修正版へ更新する前に、設定とアプリのバックアップ、現行イメージ、データベースとの互換性、停止可能時間を確認します。ただし、脆弱な実行環境へ無条件に戻す手順だけを用意してはいけません。ロールバックが必要になった場合は、対象機能を止める、入口を制限する、旧版を隔離するなど、リスクを下げる暫定策とセットにします。

4 ステージングで負の試験まで行う

• 正しい資格情報でログインでき、誤った資格情報は拒否されるか
• HTTP/2で同時リクエストと非同期エラーを発生させても応答が混ざらないか
• AJP経由で大きなレスポンスやストリーミング処理が正常に完了するか
• TLS 1.3接続とFIPS要件が期待どおり有効か
• リダイレクト後に機密データを含む処理や出力が継続しないか

本番データを使った意図的な情報混在試験は避け、テスト専用の識別可能なデータを用います。CDNやプロキシを含む本番相当経路でも確認し、アクセスログ、アプリログ、ロードバランサーのログに同じ相関IDを付けると追跡しやすくなります。

5 本番反映後に版と挙動を再確認する

デプロイ成功の表示だけでは更新完了とはいえません。各ノードで11.0.27、10.1.61、9.0.123のいずれかが稼働しているか、古いPodや待機系が残っていないか、認証失敗が正しく記録されるかを確認します。HTTP/2やAJPのエラー率、5xx、ログイン失敗率、TLSハンドシェイク失敗も更新前の基準と比較します。

更新まで時間が必要な場合の暫定策

更新を延期せざるを得ない場合は、使っていないAJPやHTTP/2コネクターを停止し、管理系の入口を制限し、JNDIRealmの該当SASL構成を見直すことが候補になります。ただし、暫定策の可否はアプリとネットワーク構成に依存します。WAFだけでは、バックエンド内部の応答対応や認証処理の不具合を直接修正できません。暫定策を恒久対応とせず、期限と責任者を設定して更新計画へ戻してください。

過去ログの確認では、同一接続・近接時刻に不自然な応答サイズやステータスの変化がないか、LDAP認証で不正な資格情報にもかかわらず成功した形跡がないかを調べます。ただし、ログだけで情報混在を完全に否定できるとは限りません。ログ保持期間や記録項目が不足している場合は、その限界を対応記録へ明記します。

判断の限界と今後の確認

本稿は2026年10月21日時点のApacheとJVNの公開情報に基づきます。各CVEのCVSSスコアは本稿で一次資料から確認できなかったため記載していません。また、攻撃への悪用状況も断定していません。Linuxディストリビューションや商用製品に組み込まれたTomcatでは、独自のバージョン表記やバックポート修正が使われる場合があります。その場合は製品ベンダーのアドバイザリとパッケージの変更履歴も確認してください。

重要なのは8件という数ではなく、自社の通信経路と認証方式にどの問題が一致するかです。まず稼働版を確定し、該当条件を記録し、修正版へ更新し、負の試験と監視で確かめる。この順序なら、緊急性を見誤らずに停止リスクと情報漏えいリスクの双方を管理できます。