2026.07.21 セキュリティ

Apache Tomcatの脆弱性（CVE-2026-59083・CVE-2026-59084）とは？影響範囲と修正版・実装者の対応

Apache Tomcatに、2026年7月14日付で2件の脆弱性 CVE-2026-59083 と CVE-2026-59084 が公表されました。前者はRewriteValveのURLデコード不備でセキュリティ制約を回避されうる問題、後者はEncryptInterceptorを安全に設定するための要件がドキュメントに明記されていなかった問題です。この記事では、影響を受けるバージョン範囲と各ブランチの修正版、自環境が該当するかの確認手順、そしてアップグレードと暫定緩和のどちらを選ぶかまでを、Tomcatを運用・受託開発する実装者の目線で整理します。深刻度はApacheセキュリティチームの評価で両件とも「低（Low）」ですが、放置してよい理由にはなりません。

目次

まとめ：修正版へ更新すれば塞げる2件の低深刻度脆弱性

2件はいずれも2026年7月14日に公開され、Apache Tomcatセキュリティチームは深刻度を「低（Low）」と評価しています（2026年7月時点）。過度に恐れる性質ではありませんが、バージョン単位で確実に塞げるため、該当ブランチの修正版へ上げる対応が最短です。

対象は 9.0.0.M1〜9.0.119、10.1.0-M1〜10.1.56、11.0.0-M1〜11.0.23 です。修正版はそれぞれ 9.0.120、10.1.57、11.0.24 で提供されています。サポート終了済みの 8.5.x は修正対象に含まれず、9.0系以降への移行が回避策になります。

CVE-2026-59083 はRewriteValveを使う構成、CVE-2026-59084 はクラスタ通信のEncryptInterceptorを使う構成で意味を持ちます。どちらの機能も使っていない環境の実質的なリスクは限定的ですが、判断を都度おこなうより、修正版へ上げて一律に塞ぐほうが運用は単純になります。受託・自社開発したJavaシステムを横断して棚卸しするなら、脆弱性診断でTomcatのバージョンと設定を洗い出す進め方が確実です。

CVE-2026-59083とCVE-2026-59084で公表された2つの問題の中身

2件は原因も影響の性質も異なります。片方はURL解釈のズレを突く実際のバイパス、もう片方はドキュメント不備に分類される問題です。まず何が起きるのかを分けて押さえます。

CVE-2026-59083：RewriteValveのURLデコード不備

TomcatのRewriteValveは、Apache HTTPD の mod_rewrite に相当するURL書き換えを担うコンポーネントです。今回の不備は、書き換え後のURIをデコードする際、リテラルの+をフォームデコードの流儀で単一のスペースへ変換していた点にあります。

問題は、このRewriteValveとTomcatのセキュリティ制約（web.xmlのsecurity-constraint）がURIの解決方法を別々に持っていたことです。両者の解釈がずれるため、+を含めて細工したリクエストが、制約側では保護対象のパスに一致するのに、書き換え側では別のパスとして通ってしまう構成があり得ます。結果として、パスに基づくアクセス制御を回避される余地が生まれました。悪用そのもの（exploitの成立）は特定の書き換え規則と制約設定の組み合わせに依存するため、成立条件は広くありません。修正はデコード処理の是正でおこなわれ、9.0.120・10.1.57・11.0.24 に取り込まれています。

CVE-2026-59084：EncryptInterceptorの設定要件の文書不備

EncryptInterceptorは、Tomcatのクラスタ（<Cluster>）でノード間の通信を暗号化するためのコンポーネントです。今回の指摘は、この機能を安全に構成するための前提条件がドキュメントに明確化されていなかった、というものでした。分類上はコードの欠陥ではなく技術文書の不備にあたります。

要件が曖昧なまま設定すると、暗号化しているつもりでも保護が十分に効かない構成に陥る余地があります。修正はドキュメントの明確化を中心におこなわれ、コミット単位で 9.0.120・10.1.57・11.0.24 に反映されました。実装者側の対応は、更新後のドキュメントに沿って鍵とチャネル構成を見直すことに尽きます。

影響を受けるTomcatのバージョン範囲と各ブランチ別修正版

影響範囲はブランチごとに異なり、修正版も個別に切られています。運用中のブランチを確認し、対応する修正版へ上げるのが基本方針です。

11.0系から9.0系までの対象バージョン範囲と修正版の対応表

2件はほぼ同じ範囲・同じ修正版で提供されています。唯一、9.0系のCVE-2026-59084のみ下限が 9.0.13 からとなります。

ブランチ CVE-2026-59083 対象 CVE-2026-59084 対象 修正版
11.0.x 11.0.0-M1〜11.0.23 11.0.0-M1〜11.0.23 11.0.24
10.1.x 10.1.0-M1〜10.1.56 10.1.0-M1〜10.1.56 10.1.57
9.0.x 9.0.0.M1〜9.0.119 9.0.13〜9.0.119 9.0.120
8.5.x サポート終了（2024-03-31以降は非対象） 修正提供なし

いずれの修正版も2026年7月14日の公表に合わせて提供されています。運用中のバージョンが対象範囲の上限（9.0.119 / 10.1.56 / 11.0.23）以下であれば、該当ブランチの修正版へ更新する対象です。

8.5.x系がサポート終了で今回の修正対象から外れる理由と移行先

Tomcat 8.5.x は2024年3月31日にサポートを終了しており、それ以降に報告された脆弱性は一覧に掲載されず修正もおこなわれません。したがって今回の2件についても、8.5.x向けの修正は提供されません。8.5.x を稼働させている場合、暫定回避ではなく 9.0系以降への移行が根本対応になります。CVEの採番や公開の仕組みそのものは、CVE（共通脆弱性識別子）とはの記事で整理しています。

自社環境が今回2件の脆弱性の影響を受けるかを確認する実務手順

影響の有無は「稼働バージョン」と「該当機能の使用有無」の2点で決まります。ここを実測してから、更新の緊急度を判断します。

稼働中のバージョンと該当機能の使用有無を切り分ける確認の順序

次の順で棚卸しすると、対象かどうかと実リスクの高さを短時間で切り分けられます。

  1. 稼働中のTomcatバージョンを確認する（catalina.sh version の出力、または lib ディレクトリの catalina.jar 内 MANIFEST.MF の Implementation-Version）。
  2. 対象範囲の上限（9.0.119 / 10.1.56 / 11.0.23）以下かを判定する。
  3. server.xml に RewriteValve の定義があるか、および rewrite.config の書き換え規則を確認する（CVE-2026-59083の実リスク判定）。
  4. <Cluster> 配下で EncryptInterceptor を使っているかを確認する（CVE-2026-59084の実リスク判定）。
  5. 該当機能を使っていれば優先度を上げ、使っていなければ通常のパッチ計画に乗せる。

脆弱性の深刻度や発見から修正までの流れそのものの前提は、脆弱性とはの記事で基礎を確認できます。

RewriteValveもEncryptInterceptorも使わない場合の実リスク

RewriteValveを使っておらず、クラスタ暗号化にEncryptInterceptorも使っていない環境であれば、今回2件の実質的な攻撃面はほぼありません。ただし「対象バージョンではある」状態は残ります。将来的に該当機能を有効化した瞬間に露出へ変わるため、機能未使用を理由に更新を無期限に見送るのは避ける判断が妥当です。悪用コードが出回るかどうかはexploitとはで扱う成立条件に左右されますが、低深刻度でも版更新で塞げるものを残す理由は薄いといえます。

修正版へのアップグレードと暫定的な緩和のどちらを選ぶかの判断

ここが実装者の判断どころです。結論を先に言うと、原則は修正版へのアップグレードで、暫定緩和は更新までのつなぎに限定します。玉虫色にせず、条件で切り分けます。

即アップグレードを推奨する場面と、通常計画に乗せてよい場面の条件

次のいずれかに当てはまるなら、定例を待たず修正版へ上げる判断を推奨します。ひとつは、外部公開されたTomcatでRewriteValveを使い、パスベースのアクセス制御（security-constraint）を効かせている構成です。もうひとつは、複数ノードのクラスタでEncryptInterceptorにより通信を暗号化している構成です。いずれも今回の不備が直接効く面を持ちます。

逆に、RewriteValveもEncryptInterceptorも使わない内部専用の単一ノードであれば、緊急更新までは求めず、次回の定例パッチで 9.0.120 / 10.1.57 / 11.0.24 へ上げる計画で足ります。ただし8.5.xだけは例外で、EOLのため定例更新の対象に「9.0系への移行」を据える必要があります。受託開発で複数案件のTomcatを抱えるなら、案件横断でバージョンと設定を洗い出す脆弱性診断・セキュリティ診断で棚卸しし、更新順序を決めると漏れが出ません。

すぐに更新できない場合の暫定緩和と、それでも避けるべき運用設計

更新を即実施できない事情がある場合、CVE-2026-59083については、書き換え規則の対象パスに+を含む細工が通らないよう、セキュリティ制約とRewriteの規則が同じパス解釈になっているかを点検します。CVE-2026-59084については、更新後のドキュメントに沿ってEncryptInterceptorの鍵長・鍵管理と、クラスタチャネルがネットワーク的に露出していないかを見直します。

避けるべき運用は明確です。RewriteValveによる書き換えだけを頼りにアクセス制御を実現し、security-constraintや上位のリバースプロキシでの制約を持たない設計は、今回の不備が直撃する失敗パターンにあたります。書き換えは経路の整形に留め、アクセス制御は制約定義や前段の制御で二重に担保する構成へ寄せる判断が安全です。診断の外注可否や費用感は脆弱性診断とはで整理しています。

Apache Tomcatの脆弱性への対応でよくある質問と実務的な回答

CVE-2026-59083・CVE-2026-59084の対応を検討する際に問い合わせの多い論点を、実装者向けにまとめます。

CVE-2026-59083とCVE-2026-59084の深刻度はどのくらいですか？

Apache Tomcatセキュリティチームは、2件とも深刻度を「低（Low）」と評価しています（2026年7月時点）。ただし低評価は「対応不要」の意味ではありません。該当機能を使う構成では実際にセキュリティ制約の回避や暗号化保護の弱体化につながる余地があるため、修正版への更新で塞ぐ対応が基本です。

どのバージョンへアップグレードすればよいですか？

ブランチごとに 11.0.24、10.1.57、9.0.120 が修正版です。運用中のバージョンが 11.0.23 / 10.1.56 / 9.0.119 以下であれば、対応する修正版が更新先になります。同一ブランチ内での更新のため、上位ブランチへの移行を伴わない構成であれば影響範囲を小さく抑えられます。

Tomcat 8.5系は修正されますか？

8.5.x は2024年3月31日にサポートを終了しており、今回の2件を含め、それ以降に報告された脆弱性への修正は提供されません。8.5.x を使っている場合は暫定回避ではなく、9.0系以降への移行が根本対応になります。移行時にはサーブレットAPIのバージョン差にも留意します。

RewriteValveを使っていなければ影響はありませんか？

CVE-2026-59083はRewriteValveを使う構成で意味を持つため、未使用であれば実質的な攻撃面はほぼありません。ただし対象バージョンである状態は残り、将来この機能を有効化した時点で露出に変わります。低深刻度でも版更新で確実に塞げるため、通常のパッチ計画に含める運用を推奨します。

EncryptInterceptorの脆弱性は何を直せばよいですか？

CVE-2026-59084はコードの欠陥ではなく、安全な設定要件の文書不備に分類されます。修正版で明確化されたドキュメントに沿い、EncryptInterceptorの鍵管理とクラスタチャネルの露出範囲を見直すことが対応になります。クラスタ暗号化を使っていない環境であれば、直接の対応は不要です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る