Tomcat脆弱性対応ガイド──8件の影響条件、AWS・Spring Boot・旧版の確認手順【2026年10月】

1. 結論：修正版へ更新し、認証方式とTomcatまでの通信経路を確かめる

情報確認：2026年10月23日（JST）。 Apache Tomcatでは10月20日に8件の脆弱性が公表され、日本のJVNも21日に情報を掲載した。上流の修正版は 9.0.123／10.1.61／11.0.27。公式ページの修正リリース見出しは10月12日、個別CVEの公表日は10月20日なので、日付の役割を分けて読む。^[1][2][3][4]

優先して調べたいのは、特定のLDAP認証設定で正しいパスワードがなくても認証できる問題と、HTTP/2やAJPの処理で別の利用者のデータが混ざる問題だ。「Tomcatが入っている」という情報から一歩進み、動作中の版、利用機能、到達経路を照合する必要がある。

OSや製品ベンダーのパッケージは、古い版番号に修正を移す「バックポート」がある。表より数字が小さいという理由だけで未修正と断定せず、対象CVE・パッケージの完全な版・配布元の告知を組にして判定する。逆に、上流に修正版があるだけで、配布元の更新が終わったとは判断できない。^[14]

本稿の提案は、「どの境界が壊れるか」を調べ、その境界に届く経路を必要に応じて制限し、修正版が全実行単位に載った証拠まで残すことだ。認証、利用者間のデータ分離、ローカル権限、暗号の動作モードは、それぞれ別の境界である。すべてを一つの設定で塞げる問題ではない。

2. 何が公表されたか：8件を機能ごとに読む

TomcatはJavaのWebアプリケーションを動かす基盤で、Apache HTTP Serverとは別の製品だ。単体で導入したサーバーだけでなく、Spring Bootのアプリにライブラリとして同梱される場合もある。アプリケーション名だけを並べた資産台帳では、下にあるTomcatが見えないことがある。^[8][10]

今回の8件は、3系列の重複を除いた数である。Apacheの分類ではImportantが3件、Lowが5件。各系列に8件すべてが当てはまるわけではなく、AJPのCVE-2026-103119は11系、APRのCVE-2026-80353は9系の今回の一覧に載る。^[1][2][3][4]

この表は優先順位をつける入口で、影響版の一覧を置き換えるものではない。例えばHTTP/2の混在は比較的新しい版に限られる一方、JNDIRealmの問題は広い範囲に及ぶ。スキャナーで一つのCVEが対象外でも、同じサーバーの他のCVEは別途調べる。

深刻度の数字が違うときは、評価者と版をセットで見る

ApacheのImportantという分類とCVSSの数値は同じ尺度ではない。今回のAmazon Linuxの評価は、認証回避がCVSS v3の7.4、HTTP/2混在が4.8。Red Hatも、製品の構成や配布方法によって評価が異なることを説明している。数値だけを横に並べて「こちらが正しい」と決めず、評価者、CVSSの版、前提条件を確認したい。^[12][13][14]

公開されたApacheとJVNの告知から、今回の8件すべてで実際の攻撃が観測されたとは読み取れない。本稿では広範な悪用が確認済みとは扱わない。ただし、告知に被害の記述がないことは、自社に影響がない証拠にはならない。更新の判断は、確認できた影響条件と扱うデータの重要性を基準に進める。

3. 認証回避：JNDIRealmの「どの方式で確認しているか」が分かれ目

CVE-2026-101296は、TomcatのJNDIRealmでGSSAPI以外のSASL認証方式を構成している場合に、正しいパスワードなしで認証が通り得る問題だ。公式の影響範囲は9.0.0.M1〜9.0.122、10.1.0-M1〜10.1.60、11.0.0-M1〜11.0.26。^[2][3][4]

Realmは、利用者とパスワード、ロールなどをTomcatの認証に結び付ける仕組みである。JNDIRealmではディレクトリサービスを参照し、認証方式は設定やプロバイダーに依存する。authentication属性には方式を指定でき、省略時はプロバイダーの既定値が使われる。設定欄が空だから対象外、と読み飛ばせない。^[7]

たとえるなら、受付で「名簿に名前がある」と確認したあと、本人確認の工程を終えずに入館証を渡してしまう状況だ。ただし、これは理解のための比喩であり、Tomcatの全認証機能が同じ不具合を持つという意味ではない。

名簿の確認と本人確認は別の工程。実際の対象判定ではRealmと認証方式を調べる。

運用担当者が確認する順番は、次のようにすると整理しやすい。

1. Tomcatが認証を担っているか。 アプリ独自のログインや外部IdPとの連携も含め、認証処理の担当を描き出す。
2. JNDIRealmを使っているか。 Engine、Host、Contextにある設定と継承、CombinedRealmやLockOutRealmの内側も確認する。
3. 実効の方式は何か。 authenticationの値、ディレクトリ側の方式、起動時に注入される設定を照合する。
4. 外から届くか、何ができるか。 一般画面だけでなく管理画面や別ポート、取得できるデータ・ロールも含める。

認証をアプリ側で実装している場合、JNDIRealmを使わないことを確認できれば、このCVEの条件からは外れる。ただしHTTP/2などの問題は残るため、記事全体の判定をそこで終えない。

暫定策として認証方式を変更するなら、既存のユーザー照合、LDAP通信の保護、ロール割当てを検証する必要がある。GSSAPIという文字を設定へ書くだけでは動作しないし、別方式へ無検証で切り替えるとログイン停止や保護の低下を招く。短時間で方式の安全性を確かめられない場合は、対象機能の公開を制限して更新の時間を確保する方が判断しやすい。

4. HTTP/2とAJP：正しくログインしていても、応答の宛先が混ざる

CVE-2026-101356は、HTTP/2で非同期Servletを処理する際の、オブジェクトの回収・再利用の不備だ。エラー処理の後に、別の利用者の要求や応答が混ざる可能性がある。影響範囲は 9.0.118〜9.0.122／10.1.55〜10.1.60／11.0.22〜11.0.26。^[5]

イメージしやすいのは、配達に繰り返し使うトレーだ。配達が途中で中断されたとき、前の宛先や中身を十分に片付けず、次の配達へ回してしまう。個々の利用者が正しくログインしていても、配達側の境界が壊れれば、データの受け手が変わり得る。アプリの認可テストだけでは拾いにくい種類の問題である。

再利用そのものではなく、異常終了を含めて前の状態を消し切れるかが境界になる。

ここで重要なのは、ブラウザーから見たHTTP/2と、Tomcatが受けるHTTP/2を分けることだ。ロードバランサーがHTTP/2を受け、TomcatへHTTP/1.1で転送していれば、その経路ではTomcatのHTTP/2処理を使わない。AWSのALBは既定でターゲットへHTTP/1.1を使い、ターゲットグループの設定でHTTP/2やgRPCを選べる。^[11]

したがって、入口の表示だけで判定せず、ターゲットグループ、リバースプロキシの上流設定、TomcatのConnector、直接到達できるポートをつなげて確認する。HTTP/2を止める場合も、止める場所はTomcatへ届く経路である。前段だけを変えて内部の別経路を残したり、gRPCへの影響を見ず切り替えたりしない。

AJPは「内部専用」でも、複数利用者の応答を運ぶ

CVE-2026-103119は、11.0.0-M25〜11.0.26のAJP処理にあるバッファーの読み取り不備で、大きな非ブロッキング書き込みの応答本文が、現在と後続の要求に分かれて届き得る。Apacheは、後続要求の失敗が最も起きやすく、最初の応答のデータが後続へ漏れる可能性もあると説明している。^[6]

AJPをインターネットへ直接公開していなくても、フロントのWebサーバーが複数利用者の要求を中継するなら、その応答の分離は重要だ。「内部ネットワークだから無関係」と閉じず、AJPを通る利用者とデータを確認する。使っていないConnectorは停止し、必要な場合は修正版への更新を優先する。

HTTP/2トレーラーのCVE-2026-88041も、前の要求の情報が後続へ残る問題だ。本文末尾に追加されるメタデータをアプリがどう扱うかも調べる。一方、TLS接続失敗やJSTLの処理継続は別の条件で起きるので、HTTP/2を止めたことを8件全体の解決に数えない。^[3]

5. どこに入っているか：単体Tomcat、Spring Boot、コンテナを棚卸しする

以下は、公開情報を実際の運用へ落とすための確認案である。コマンドのパスや対象名は例であり、参照する環境を確定してから使う。取得した設定やログには認証情報が含まれ得るので、共有する記録には必要な項目だけを残す。

単体Tomcatでは、起動対象のインストール先を特定し、そのバイナリの版を調べる。

/path/to/running-tomcat/bin/version.sh

これはそのディレクトリにあるTomcatの版を示す。実行中プロセスが別の場所から起動している可能性があるため、サービス定義、起動ログ、CATALINA_HOMEとCATALINA_BASEを照合する。置き換え済みのファイルを見ただけでは、古いJavaプロセスが止まった証拠にならない。

Spring Bootでは、アプリに組み込まれたTomcatの依存関係を調べる。Servlet系の構成にはTomcatが同梱されることがあり、OSのTomcatパッケージ一覧に出ない。WebFluxなど別サーバーの構成もあるので、Spring Bootという名前だけで有無を決めない。^[10]

# Mavenプロジェクトの依存関係
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed

# Gradleプロジェクトの実行時依存関係
./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath

# 実際に配布するSpring Boot JAR内も確認
jar tf application.jar | rg 'BOOT-INF/lib/tomcat-embed-'

依存関係の結果と成果物が違えば、ビルド対象、キャッシュ、依存関係管理、配布したファイルを確認する。基本は利用中のSpring Boot系列が管理する依存関係と互換性を踏まえた更新を選び、TomcatのJARだけを場当たり的に差し替えない。緊急に版を上書きする場合も、関連するTomcatモジュールを揃え、アプリの回帰テストを通す。

コンテナでは、ビルド元と稼働中を分けて記録する。ベースイメージを更新しても、アプリJARに古いTomcatを含めていれば残る。逆にJARを直しても、旧タスクやPodが動いていれば公開経路に未修正の実行単位が残る。

• イメージのタグと不変のダイジェスト、内包するTomcatの版を記録する。
• 全レプリカの入れ替えと、旧実行単位への新規流入停止を確認する。
• オートスケールや障害復旧が参照する定義も更新する。
• ロールバック先が未修正なら、復旧後の制限と再更新の手順を決める。

台帳の1行は「サーバー1台」より、サービス・環境・実行成果物・入口・担当者の組にすると漏れを減らせる。検証環境や管理用ツールでも、実データや本番認証へ届くものは優先度を上げたい。

6. AWSと旧版：配布待ち、責任分担、バックポートを分ける

10月23日の確認時点で、Amazon LinuxのCVEページには次の状態が掲載されている。対象は主要な2件であり、残りのCVEを含む製品全体の修正完了表ではない。^[12][13]

Pending Fixは修正済みを意味しない。 パッケージ更新コマンドが正常に終わっても、対象CVEの修正版がまだリポジトリへ届いていなければ修正は入らない。ここは変化の速い情報なので、作業時にCVEページのAdvisory欄と修正パッケージの版を読み直す。

例えば、Amazon Linuxのパッケージ情報は次のように確認できる。出力の有無だけで解決とせず、アドバイザリへ照合する。

rpm -qa | rg '^tomcat'
dnf updateinfo info --cves CVE-2026-101296,CVE-2026-101356

上のdnf例は対応する環境向けで、AL2の運用手順をそのまま置き換えるものではない。また、手動配置やアプリ同梱のTomcatはRPMの一覧に出ない。OS側とアプリ側の棚卸しをつなげる必要がある。

上流で修正が完成してから、配布物になり、稼働中へ届くまでには別々の工程がある。

AWS上でも、誰が更新するかは配置方法で変わる。EC2上へ自分で導入したTomcat、ECS・EKSのアプリイメージ、製品ベンダーが管理するソフトウェアでは、確認先と変更担当が異なる。「AWSを使っている」だけでは自動更新の範囲は決まらない。担当チームには、サービス名だけでなく、どの成果物を誰が再構築・再配置するかを聞く。

配布元を変えるなら、次の更新も引き受けられるか

修正待ちの間に、上流の配布物へ切り替える選択肢はある。ただしパッケージ管理から外れると、起動方法、ファイルの所有者、ログの位置、次回の更新担当などが変わり得る。緊急時のコピーで終わらせず、導入と復旧の手順、保守の持ち主を残す。独自のソースバックポートは、検証と継続保守を担える場合の選択肢だ。

古い系列を大きく上げるときには、Javaの要件やAPIの互換性も関わる。現行の上流要件はTomcat 9がJava 8以上、10.1が11以上、11が17以上である。9から10以降への移行にはJava EEからJakarta EEへの変更もあるため、今回の修正と長期の移行を同じ締切へ押し込まない。^[8][9]

ベンダーへは「対応していますか」だけでなく、製品版、同梱Tomcat、各CVEへの該当性、修正済み配布物、適用手順、再起動の要否を問い合わせる。サポート終了系列は、最新の告知に名前がないことを安全の証拠にしない。調査対象から外れている場合と、影響がないと確認された場合は違う。

7. すぐ更新できないとき：止める対象と、継続できる条件を決める

ここからは本稿の運用提案であり、Apacheが8件すべてに保証する万能の回避策ではない。暫定策は対象CVEと経路を限定して記録し、期限と再確認の担当を付ける。

公開を止める・絞る判断を優先するケース。 対象の認証設定が使われ、重要データや管理操作に外部から到達できるのに、すぐ修正できない場合。あるいは、HTTP/2やAJPの影響経路でデータ混在を疑う兆候がある場合。入口のアクセス制限、影響する機能の停止、対象実行単位の切り離しを検討し、疑わしいログを保全する。

対象経路を外して、期限付きで継続を検討できるケース。 例えば、HTTP/2の影響経路をHTTP/1.1へ切り替え、直接到達経路を閉じ、認証など他のCVEを個別に確認できた場合。ただし、性能、非同期処理、gRPCなどへの影響は事前に確認する。「一つ無効化した」ではなく、「このCVEが動く経路を外した」という証拠が必要だ。

調査中として扱うケース。 ベンダー製品で設定も内包版も分からない場合や、バックポートの証拠が取れない場合。対象外に丸めず、露出とデータの重要性に応じて制限し、回答期限を決める。

WAFは追加の防御にはなるが、サーバー内部のオブジェクト再利用やLDAP認証の実装を修正しない。今回の特定CVE向けルールを採用する場合も、提供元が明示する対象と限界を読む。一般的な攻撃ルールを有効にしただけで、応答の利用者間混在を防げるとは判断できない。

また、アプリ内のメンテナンス画面では、リクエストがTomcatへ届いてから表示される構成がある。到達を止めたい場合は、その前段で遮断されていることを確認する。管理ポート、内部経路、別のホスト名を含めて、制限の外側に入口が残らないかを見る。

8. 完了の条件：更新した版と、実際に動く版を一致させる

更新の作業票は、コマンドの終了コードだけで閉じない。次の4点を揃えると、担当が交代しても完了を説明できる。

1. 修正の根拠。 上流の修正版、または対象CVEを明記した配布元のアドバイザリと完全なパッケージ版。
2. 稼働の根拠。 起動ログ、成果物の識別子、イメージのダイジェスト、全実行単位の入れ替え結果。
3. 機能の根拠。 正常・誤パスワードの認証、権限の異なるテスト利用者、非同期応答、通信経路など、利用機能に対応した回帰確認。
4. 再発防止の根拠。 新規起動の定義、復旧先、更新担当、暫定制限を解除する条件。

テストには専用のアカウントとデータを使い、他人の情報を取得することを確認方法にしない。簡単な試験で混在が再現しなかったとしても、タイミングに依存する不具合の不存在は証明できない。修正済みの実装が動いている証拠を中心に、機能試験で運用上の不具合を確かめるのが現実的だ。

代表1台ではなく、次に起動する個体も含めて修正版が行き渡ったことを確かめる。

調査ログでは、認証成功とアプリの操作履歴の不整合、利用者の申告、非同期処理のエラー、異常な応答などを時系列で照合する。アクセスログが成功を示していても、届いた本文まで正しいとは限らない。疑いがあるときは、運用ログだけから「漏えいなし」と断定せず、セキュリティ担当と対象範囲・証拠保全を決める。

PHP2Shellの対応経験から引き継げること

PHP2Shellの記事と共通するのは、アプリの下にある実行基盤の棚卸し、配布元の修正確認、そして更新後の稼働確認だ。今回のTomcatでは、そこへ認証方式とプロトコルの実効設定が加わる。同じ週の脆弱性でも、同じ暫定策や停止判断をそのまま当てはめない。

今日の着手点は、サービスごとに「動くTomcat」「実効のRealm」「Tomcatへ届くプロトコル」「修正配布物」「再起動後の証拠」を埋めること。対象外なら理由を残し、対象なら更新担当と期限を決め、未確認なら未確認のまま可視化する。この整理があれば、次の告知が来たときに全員で同じ調査をやり直す負担も減らせる。

本稿は公開された一次資料をもとにした解説で、個別環境での再現試験や侵害調査を実施した報告ではない。配布状況は変わるため、適用時にはリンク先の最新情報と製品ベンダーの指示を確認してほしい。