Apache Tomcatに『危険度9.1』の脆弱性と出るが、開発元評価は『低』 CVE-2026-59083/59084、慌てず定例更新でよい理由

社内のセキュリティ検査ツールやニュースで「Apache Tomcatに危険度9.1（Critical）の脆弱性」と表示され、身構えた方もいるかもしれません。結論から言うと、あわてて緊急対応に走る必要はありません。今回公表された2件の脆弱性（CVE-2026-59083とCVE-2026-59084）は、開発元であるApache自身の評価では「低（Low）」です。実際に攻撃に使われた報告もありません。

Apache Tomcatは、Javaで作られたWebシステムを動かすためのソフトで、日本の企業システムの裏側で広く使われています。それだけに「Critical（緊急）」の表示が出ると、現場は一斉に警戒モードに入りがちです。ところが、その「9.1」という数字と、開発元の「低」という評価は、大きく食い違っています。この記事では、なぜ数字が食い違うのか、自分の環境は本当に影響を受けるのか、そして落ち着いて何をすればいいのかを、順を追って整理します。

何が公表されたのか

2026年7月14日、Apache Tomcatに2件の脆弱性が公表され、日本の脆弱性情報ポータルJVN（JVNVU95286373）でも「Apache Tomcatにおける複数の脆弱性」として案内されました。内容は次の2件です。1件はURLの解釈のずれによるアクセス制御の回避が起こりうるもの、もう1件はそもそもプログラムの欠陥ではなく、設定手順の説明（ドキュメント）が不十分だったという問題です。

どちらも、外部から誰でも簡単にサーバーを乗っ取れる、といった類のものではありません。悪用には特定の設定条件が必要で、実際に攻撃されている事実も、攻撃を再現する実証コード（PoC）の公開も、現時点で確認されていません。米政府CISAが公開する実際に攻撃されている脆弱性のリスト（KEV）にも登録されていません。

脆弱性の概要

CVE-2026-59083：URLの解釈のずれでアクセス制御を回避しうる

Tomcatには、アクセスされたURLを内部で書き換える「RewriteValve」という機能があります。今回の問題は、書き換えたあとのURLに含まれる「+（プラス）」記号を、Tomcatが誤って半角スペースに解釈してしまう場合があった点です。この解釈のずれを利用すると、本来はアクセス制御（セキュリティ制約）で守られているはずのパスに、条件次第で到達できてしまう可能性があります。ただし、これはサーバーを乗っ取るRCE（遠隔コード実行）ではなく、成立するのも「RewriteValveを使い、かつ特定の設定になっている」環境に限られます。分類はURLエンコードの取り扱い不備（CWE-177）で、Tomcatのセキュリティチームが自ら発見しました。開発元Apacheの深刻度評価は「低」です。

CVE-2026-59084：暗号化設定の説明（ドキュメント）不足

2件目は、複数のTomcatを束ねて動かす「クラスタ」構成で、サーバー間の通信を暗号化する「EncryptInterceptor」という仕組みに関するものです。ここで重要なのは、これはプログラムの欠陥ではなく、安全に設定するための要件がドキュメントに十分書かれていなかった、という「説明不足」の問題だという点です。分類も、技術文書の不備（CWE-1059）です。実際に影響が出るとすれば、この暗号化を誤った設定のまま使っていた組織で、期待した保護が効いていなかったかもしれない、という限られたケースです。こちらも開発元評価は「低」です。

なぜ「9.1」と「低」が食い違うのか

ここが今回いちばん大事なところです。同じ脆弱性なのに、片や「9.1（Critical）」、片や「低」。この差は、スコアを付けている主体と方法が違うことから生まれています。

脆弱性の深刻度は、CVSS（共通脆弱性評価システム）という国際的なものさしで0.0〜10.0の数値に表されます。今回「9.1」という数字が出回っているのは、米政府の関連組織が脆弱性データベース（NVD）に付けた自動補完のスコアです。詳しい前提条件を一つひとつ確かめる前に、機械的に「最悪の場合」を想定して付けられることがあり、実際の悪用しやすさより高めに出やすい性質があります。一方、「低」という評価は、この脆弱性を最もよく知る開発元Apache（採番元）が、成立条件や実際の影響を踏まえて付けたものです。

その食い違いが極端に表れているのが、ドキュメント不足のCVE-2026-59084です。プログラムを直したわけではなく説明書きを補っただけの案件にも、自動補完では9.1という高い数字が付いています。これは明らかに実態と合っていません。多くの商用スキャナはこの自動補完値をそのまま取り込んで表示するため、社内の検査で「Critical検出」と警報が鳴っても、中身は緊急とは限らない、ということが起こります。数字だけを見て慌てるのではなく、採番元（開発元）の評価と、実際に攻撃されているかどうかを合わせて見るのが、正しい向き合い方です。

自分の環境は影響を受けるのか

落ち着いて確認しましょう。今回の2件が実際に関係するのは、次のような環境に限られます。当てはまらなければ、実質的な影響はほとんどありません。

修正版は、サポートが続いている系統ごとに用意されています。対象と修正版は次の通りです。なお、Tomcat 8.5系（および7.0系）はすでにサポートが終了しているため、これらを使っている場合は、そもそも今回の件に関わらずサポートの続く9.0系以降へ移行するのが本筋です。

では何をすればいいのか

対応はシンプルです。次回の定例メンテナンスのタイミングで、サポート系統の修正版（9.0.120／10.1.57／11.0.24）へ更新する。これで十分です。今すぐサービスを止めて緊急パッチを当てる、といった対応は求められていません。ただし、前の章の表で「確認対象」に当てはまった環境（RewriteValveの利用、クラスタでの暗号化通信）は、更新にあわせて設定を見直しておくと安心です。

今回いちばん持ち帰ってほしいのは、スキャナが出す「Critical」の一言だけで判断しないという姿勢です。数字が高くても、実際に悪用されているか（KEVへの登録の有無）、悪用の起きやすさ（EPSSという指標）、そして採番元の評価まで合わせて見れば、本当に急ぐべきか、定例で足りるのかが見えてきます。Apache関連では、同じく評価が過熱しやすい話題として、AIが発見したHTTP/2の停止攻撃や、ログイン不要で悪用されるApache MINAの脆弱性のように、実際の深刻度は案件ごとに大きく異なります。一件ずつ、数字の裏側まで確かめる習慣が、無駄な火消しと本当の緊急の見落とし、どちらも防ぎます。

よくある質問

Q. スキャナで「Critical 9.1」と出ました。放置していいのですか。

A. 放置ではなく「あわてず定例で更新」が適切です。9.1は自動補完のスコアで、採番元Apacheの評価は「低」、実際の悪用も確認されていません。次のメンテナンスで修正版へ上げれば十分です。ただしRewriteValveやクラスタ暗号化を使っている場合は、更新時に設定も確認してください。

Q. なぜ開発元とスキャナで深刻度が違うのですか。

A. スキャナが表示するのは、脆弱性データベースに機械的に付けられた「最悪の場合」寄りの自動補完値であることが多いためです。採番元（開発元）は成立条件や実際の影響を踏まえて評価するため、より実態に近くなります。数字が食い違うときは、採番元の評価と実際の悪用状況を優先して判断してください。

Q. うちのTomcatは8.5系です。どうすれば。

A. Tomcat 8.5系はすでにサポートが終了しており、今後は新しい修正が提供されません。今回の件に関係なく、サポートの続く9.0系以降への移行を計画してください。サポート切れのまま本番で使い続けること自体が、より大きなリスクです。

まとめ

Apache Tomcatに公表された2件の脆弱性（CVE-2026-59083・CVE-2026-59084）は、スキャナやニュースで「危険度9.1（Critical）」と表示されることがありますが、開発元Apacheの評価はいずれも「低」で、実際に攻撃された報告もありません。1件はRewriteValveの特定設定でのアクセス制御回避、もう1件はそもそもドキュメントの不足であり、緊急でサービスを止めて対応する類のものではありません。

やるべきことは、定例のタイミングで9.0.120／10.1.57／11.0.24へ更新すること、そしてRewriteValveやクラスタ暗号化を使っている環境は設定を確認すること。それで十分です。今回の一件は、「Critical」という表示に振り回されず、採番元の評価・実際の悪用状況・悪用のしやすさまで見て判断するという、脆弱性対応の基本を思い出させてくれる事例でもあります。

参照元

• ▸JVN - JVNVU95286373 Apache Tomcatにおける複数の脆弱性
• ▸NVD - CVE-2026-59083
• ▸NVD - CVE-2026-59084
• ▸Apache Tomcat - Security（公式・深刻度評価）
• ▸oss-security - Apache Tomcat 脆弱性告知（2026年7月14日）