Apache Tomcatに2件の脆弱性（CVE-2026-59083／CVE-2026-59084）が公表されました。いずれもApacheの深刻度評価は「Low（低）」ですが、うち1件はRewriteValveを使っている環境で「URLに基づくアクセス制御を回避される」可能性がある点に注意が必要です。もう1件はクラスタ通信の暗号化設定（EncryptInterceptor）に関する文書不備です。いずれも修正版（11.0.24／10.1.57／9.0.120）へのアップデートで解消します。
緊急の広範な悪用が確認されている類のものではありません。まずは「自社でRewriteValveやクラスタ機能を使っているか」を切り分け、通常のパッチ運用の中で計画的に更新するのが現実的です。
この記事でわかること
- 今回の2件の脆弱性の概要と深刻度
- 影響を受けるバージョンと修正版
- 「自社は影響するのか」を切り分けるための確認ポイント
- 情シスとして取るべき対応の優先度
何が起きたのか
Apache Software Foundationは2026年7月14日、サーブレットコンテナ／Webサーバである Apache Tomcat に2件の脆弱性を公表しました。JVNにも2026年7月17日付で登録されています。概要は次のとおりです。
| CVE番号 | 種類 | Apacheの深刻度 | 影響する条件 |
|---|---|---|---|
| CVE-2026-59083 | RewriteValveのURLデコード不備によるアクセス制御回避 | Low（低） | RewriteValve（rewriteルール）を使用している環境 |
| CVE-2026-59084 | EncryptInterceptorの設定要件に関する文書不備 | Low（低） | クラスタ通信でEncryptInterceptorを使用している環境 |
ポイントは、どちらも「Tomcatを動かしていれば必ず影響する」ものではなく、特定の機能を使っている場合に限って関係するという点です。だからこそ、闇雲に慌てるのではなく、自社の構成を確認してから優先度を決めるのが合理的です。
影響を受けるバージョンと修正版
Apacheの公表情報によると、影響を受けるバージョンと修正版は以下のとおりです（2件で共通）。
| 系統 | 影響を受けるバージョン | 修正版 |
|---|---|---|
| Tomcat 11 | 11.0.0-M1 〜 11.0.23 | 11.0.24 |
| Tomcat 10 | 10.1.0-M1 〜 10.1.56 | 10.1.57 |
| Tomcat 9 | 9.0.0.M1 〜 9.0.119 | 9.0.120 |
CVE-2026-59083については、旧系統である Tomcat 8.5系（8.5.0〜8.5.100）も影響を受けるとされています。Tomcat 8.5系はすでにサポート終了（EOL）を迎えているため、修正版の提供対象外です。まだ8.5系を使っている場合は、この機会にサポート中の系統への移行を検討してください。
CVE-2026-59083：RewriteValveの「+」の解釈がずれる問題
この脆弱性は、RewriteValveがURIを書き換えた後のデコード処理で、リテラルの「+」を空白文字として解釈してしまうことに起因します。この解釈のずれにより、リクエストパスに基づいて設定したセキュリティ制約（アクセス制御）が、一部の構成で回避される恐れがあります。
Tomcatの RewriteValve は、Apache HTTP Server の mod_rewrite に相当するURL書き換え機能です。rewrite.config にルールを書き、URLの正規化やリダイレクト、内部書き換えを行っている環境が対象になります。逆に言えば、RewriteValveを使っていなければ、この脆弱性の直接の対象ではありません。
深刻度が「Low」に留まっているのは、悪用にrewriteルールと保護対象パスの特定の組み合わせが必要で、条件が限定的なためと考えられます。とはいえ「URLのパスで認可を分けている」構成は実務でよくあるため、RewriteValveを使っている場合は軽視せず修正版を当てるべきです。回避策（設定変更による緩和）は明示されておらず、対応は修正版へのアップグレードが基本になります。
CVE-2026-59084：EncryptInterceptorの「設定の落とし穴」
もう1件は、コードのバグというよりドキュメントの不備に分類される脆弱性です。Tomcatのクラスタ機能では、ノード間通信を暗号化するために EncryptInterceptor を使いますが、その安全な設定要件が明確に文書化されていなかった、というものです。要件を正しく理解しないまま設定すると、暗号化保護が実効的に効かない構成になり得ます。
該当するのは、複数ノードでTomcatクラスタを組み、セッションレプリケーション等でノード間通信を行っている環境です。単体構成では基本的に関係しません。修正版では文書と挙動が改善されています。クラスタを運用している場合は、更新とあわせて自社のEncryptInterceptor設定を見直しておくとよいでしょう。
現場目線の課題
Tomcatのようなミドルウェアの難しさは、「どこで動いているか把握しきれない」ことにあります。自社製の業務システムはもちろん、パッケージ製品やベンダー納品のシステムに組み込まれた形でTomcatが同梱されているケースは珍しくありません。情シスが直接管理していないサーバの中で、古いTomcatが静かに動き続けている──という状況が起きがちです。
今回のように「特定機能を使っている場合のみ影響」という条件付きの脆弱性は、影響判定そのものに手間がかかります。RewriteValveやクラスタの利用有無は、アプリの構成ファイルを1台ずつ確認しないと分からないことも多く、台数が増えるほど確認コストは無視できません。限られた人員で全台を追い切る難しさは、多くの現場に共通する悩みどころではないでしょうか。だからこそ、平時からの資産・構成管理（どのサーバにどのミドルウェアが載っているか）の整備が、いざというときの初動を大きく左右します。
情シスはどうすべきか
今回の2件は深刻度Lowで、即時の広範な悪用が確認されているわけではありません。次の手順で落ち着いて対応すれば十分です。
- 棚卸し：自社（および委託先納品システム）でTomcatを使っている箇所と、そのバージョンを洗い出す。
- 影響判定：RewriteValve（rewriteルール）やクラスタ＋EncryptInterceptorを使っているかを確認する。使っていれば優先度を一段上げる。
- 更新：通常のパッチ運用の中で、修正版（11.0.24／10.1.57／9.0.120）へ計画的にアップデートする。EOLの8.5系はサポート中系統への移行を検討する。
脆弱性の「自社への影響度」を素早く見積もる考え方や、深刻度スコアの読み方については、過去記事も参考にしてください。パッチ適用の優先順位付けは日々の運用の肝です。関連して、Webサーバ／リバースプロキシの脆弱性対応の実例としてnginx脆弱性CVE-2026-42533の解説、パスに基づく防御を補う仕組みとしてWAFとは？（仕組み・導入時の注意点）もあわせてどうぞ。緊急対応が求められた事例としてはSharePoint Server脆弱性でCISAが緊急対策を要請した件も、優先度判断の参考になります。
脆弱性管理全般の進め方は、IPAの公的資料が体系的です。まずは中小企業の情報セキュリティ対策ガイドラインに目を通し、自社の運用に落とし込むとよいでしょう。地道な資産管理と、担当者・利用部門への継続的な啓発が、こうした「条件付き脆弱性」の見落としを防ぎます。
まとめ
- Apache Tomcatに2件の脆弱性（CVE-2026-59083／CVE-2026-59084）。深刻度はいずれもApache評価でLow。
- 影響は条件付き。RewriteValve利用時はアクセス制御回避、クラスタ＋EncryptInterceptor利用時は暗号化設定の不備が論点。
- 対応は修正版（11.0.24／10.1.57／9.0.120）への更新が基本。まずは自社のTomcat棚卸しと機能利用の確認から。
出典
- JVNDB-2026-024105 Apache Tomcatにおける複数の脆弱性(2026年7月14日)：https://jvndb.jvn.jp/ja/contents/2026/JVNDB-2026-024105.html
- oss-security: CVE-2026-59083 Apache Tomcat: Incorrect URL decoding in RewriteValve may allow security control bypass：https://www.openwall.com/lists/oss-security/2026/07/14/7
- Apache Tomcat セキュリティ情報（各系統）：tomcat.apache.org/security-11.html ほか
- NVD: CVE-2026-59083 ／ CVE-2026-59084
