Apache Tomcat複数脆弱性がJVNで公表｜「うちにTomcatはあるか」に即答できない会社が、パッチより先に直すべきもの

最初に結論を書く。2026年7月16日、JPCERT/CCとIPAが共同運営する脆弱性情報ポータルJVNに「Apache Tomcatにおける複数の脆弱性」（JVNVU#95286373）が掲載された。対象はCVE-2026-59083とCVE-2026-59084の2件で、Apache公式の深刻度評価はいずれも「Low（低）」。公表時点で悪用は確認されておらず、修正版（9.0.120／10.1.57／11.0.24）も既に出ている。つまり今回は、徹夜で対応するような事案ではない。

それでもこのニュースを記事にするのは、多くの中堅・中小企業がこの公表を見て確認すべきことが、脆弱性の中身ではないからだ。確認すべきは、「うちのどこかでTomcatは動いているか」という問いに、自社が何分で答えられるかである。即答できる会社にとって、今回の公表は5分で終わる定例作業だ。答えられない会社にとっては、次にCVSS満点級の脆弱性が来た日に、確認だけで1週間を溶かす予行演習の失敗である。深刻度がLowだった今回こそ、ノーダメージで体制の穴を測れる貴重な機会だと捉えてほしい。

本稿では脆弱性の技術解説は最小限にとどめ、「注意喚起や脆弱性公表が出た日に自社が動ける状態」をどう作るかを扱う。具体的には、即答すべき3つの問い、初動24時間からの対応手順表、そして外注先との保守契約に入れるべき10項目のチェックリストを提供する。

この記事が向いている読者

• 5年以上前に外注で作った業務システムが、中身を誰も説明できないまま動き続けている会社の経営者
• 「Tomcatって、うちにありましたっけ」と聞かれて調べる手段が思いつかない兼任情シス・ひとり情シス
• 保守契約は結んでいるが、その契約書に「パッチ適用」の文字があるか確認したことがない管理部門
• JVNやJPCERT/CCの情報が毎週流れてくるたび、対応すべきか放置してよいか判断できず消耗している担当者
• システムの発注はするが、納品後のソフトウェア部品の面倒を誰が見るのか、契約で決めた記憶がない発注責任者

一つでも心当たりがあれば、読む価値はある。逆に、自社のソフトウェア資産台帳が整備され、脆弱性トリアージの当番が決まっている会社には、本稿の後半のチェックリストだけ流し読みしてもらえば十分だ。

今回の公表内容を3分で整理する

まず事実関係を一次情報ベースで固定する。感想や推測を挟まず、ここだけ読めば技術面の把握が終わる状態にした。

補足を3点だけ加える。第一に、CVE-2026-59083が刺さるのは、URL書き換え（RewriteValve）の結果を前提にアクセス制御を組んでいる構成だ。該当構成でなければ実質的な影響は小さいが、「自社のシステムが該当構成かどうか」は構築したベンダーにしか分からないことが多い。ここが後述する本題につながる。第二に、CVE-2026-59084は厳密にはソフトウェアの欠陥というよりドキュメントの不備であり、クラスタ構成でEncryptInterceptorを使っていなければ関係しない。第三に、注意すべきは影響バージョンの下限の広さだ。9.0系の初期から対象ということは、数年前に構築されて一度も更新されていないTomcatは、ほぼ確実に影響範囲に入っている。さらに言えば、8.5系以前のTomcatは既にサポートが終了しており（8.5系は2024年3月末でEOL）、今回のような修正版の提供自体がない。古い受託システムでまず疑うべきはこちらである。

同じ週に、これだけの公表が並んでいた

もう一つ知っておくべき文脈がある。Tomcatの公表は、この週のJVN掲載のごく一部でしかない。同じ7月16日には、SSH接続に広く使われるターミナルソフトTera TermのTTSSH2プラグインの複数脆弱性（JVN#65294474）が公表された。同日には、JavaScriptの暗号ライブラリForgeの署名検証不備（JVNVU#98998987）と、Pegatron製WDMドライバ「Tdelo64.sys」の複数脆弱性（JVNVU#90340653）も並んでいる。翌17日には、一部HTTP/2サーバーのフロー制御に起因するDoS脆弱性（JVNVU#90338324）と、LLM推論サーバーSGLangのデシリアライゼーション脆弱性（JVNVU#90968686）が続いた。

つまり、脆弱性情報は「たまに来る大事件」ではなく「毎週数件届く定期便」である。この前提に立つと、対応のあるべき姿が変わる。1件ごとに慌てて調べ、判断できずに放置し、次の1件でまた慌てる——このループを繰り返す会社は、担当者が消耗するだけで安全にはならない。必要なのは、届いた情報を「うちに関係あるか」で数分で仕分けできる仕組みであり、その仕組みの土台がソフトウェア資産台帳だ。台帳がなければ、どんなに真面目な担当者でも仕分けのしようがない。

なぜ「うちにTomcatはあるか」に答えられないのか

Tomcatは、Javaで作られたWebアプリケーションを動かすための実行基盤（サーブレットコンテナ）である。ここで重要なのは、Tomcatを「自社で選んで導入した」認識のある会社はむしろ少数派だという点だ。典型的な入り込み方は次の3つである。

第一に、受託開発の部品として。業務システムをJavaで外注した場合、納品物の内部でTomcatが動いているケースは非常に多い。発注側が指定したわけではなく、開発会社の標準構成として選ばれ、納品書にも契約書にも「Tomcat」の文字は出てこない。第二に、パッケージ製品の同梱部品として。勤怠管理、ワークフロー、帳票、グループウェアなどの社内設置型パッケージには、実行環境としてTomcatを同梱しているものがある。利用企業から見えるのは製品名だけで、中身のTomcatは意識されない。第三に、サーバー移設の生き残りとして。過去のリプレイスやクラウド移行の際に「動いているからそのまま」で持ち越された旧システムの中で、当時のバージョンのまま動き続けている。

この構造が意味するのは、「うちにTomcatはあるか」という問いが、実は「うちの業務システムの中身を、誰が把握しているか」という問いだということだ。そして多くの中堅・中小企業では、その答えは「構築したベンダーだけが知っている。ただしそのベンダーが今も把握しているかは分からない」である。

さらに深刻なのは契約の空白だ。システムの保守契約を結んでいても、その中身が「障害が起きたら対応する」「操作の問い合わせに答える」に限定されていて、ミドルウェアやOSSコンポーネントへのセキュリティパッチ適用が業務範囲に入っていない契約は珍しくない。この場合、脆弱性が公表されても、ベンダーには通知する義務も適用する義務もない。発注側は「保守を頼んでいるから大丈夫」と思い込み、受注側は「言われていないからやらない」——どちらも契約上は正しく、そして誰もパッチを当てないまま数年が経過する。これは特定のベンダーの怠慢というより、発注時に誰もこの論点を契約に載せなかったという構造の問題だ。システム開発の受発注の現場で繰り返し起きているのは、悪意ではなくこの「決めていなかった」である。

古い業務システムの部品が放置されて狙われる構造については、ColdFusionを例にレガシー放置の代償を整理した記事でも書いた。あちらはCVSS満点級の緊急対応の話だったが、根っこは今回とまったく同じ「中身を誰も知らないシステム」の問題である。

脆弱性公表の日に即答すべき3つの問い

体制ができているかどうかは、次の3つの問いで測れる。今回のTomcatの件を材料に、実際に社内で試してみてほしい。

問い1：うちのどこかでTomcatは動いているか？ 社内サーバー、データセンター、クラウド上の仮想マシン、そして外注した業務システムとパッケージ製品の中身まで含めての問いだ。「分からない」なら台帳が存在しない。「ベンダーに聞けば分かるはず」なら、台帳がベンダー任せで自社に写しがない状態である。

問い2：動いているなら、バージョンは何で、修正版を当てるのは誰の仕事か？ バージョンが分からなければ影響有無を判定できない。当てる責任者が答えられなければ、保守契約の責任分界が決まっていない。「保守会社がやってくれるはず」の「はず」が出てきたら、契約書を開いて確認するサインだ。

問い3：当てない・当てられない場合、その判断を誰がいつ記録するか？ すべての脆弱性に即パッチが正解とは限らない。今回のようにLowで悪用未確認なら、次回定期メンテナンスまで見送る判断は十分に合理的だ。ただし「確認したうえで急がないと判断した」と「そもそも知らなかった」は、結果が同じでもまったく別物である。前者は経営判断、後者は無防備だ。判断の記録が残らない会社は、事故が起きたときに「知らなかった」しか言えなくなる。

3問すべてに30分以内で答えられるなら、体制は合格圏にある。1問でも詰まったなら、以降の手順表とチェックリストが自社の宿題になる。

対応手順表：初動24時間・1週間・恒久対策

今回のTomcat公表を例に、時間軸で何をすべきかを整理する。深刻度Lowの今回はこの表を落ち着いて試せるが、同じ流れはCritical級が来た日にも使う。むしろ、平時に一度回しておくことが、緊急時に手が動く唯一の準備である。

恒久対策の「仕分けの仕組み化」は、具体的には次のような週次ルーチンで成立する。情報源はJPCERT/CCの注意喚起・Weekly ReportとJVNの新着に絞り、メール配信かRSSで受け取る（あれこれ購読を増やすより、この2系統を確実に読むほうが実効性が高い）。担当者は週に一度15分、届いた公表一覧を台帳の部品欄と突き合わせ、「該当なし」「該当あり・ベンダー照会」「該当あり・自社対応」の3択に仕分けて1行ずつ記録する。判断に迷うものは「照会」に倒す。これだけである。セキュリティ専任者は要らず、必要なのは台帳と15分の習慣だけだ。逆に言えば、台帳がない状態でどれだけ情報を購読しても、毎週「うちに関係あるのだろうか」という不安が積み上がるだけで、1件も仕分けられない。

強調したいのは、初動24時間の主作業が「パッチを当てること」ではなく「照会を出すこと」だという点だ。外注中心の中小企業にとって、脆弱性対応の実作業はほとんどの場合ベンダーの手で行われる。だから自社側の勝負は、正しい相手に、期限付きで、書面で聞けるかに懸かっている。台帳とは、この照会を24時間以内に出すための宛先リストにほかならない。

保守契約チェックリスト10項目

恒久対策の核心は契約だ。次の10項目を、現在の保守契約書と突き合わせてほしい。何項目が明文化されているかが、そのまま自社の脆弱性対応力である。新規発注の際は、この10項目を提案依頼の段階で提示すると、ベンダーの保守体制の実力も見える。

1. 構成部品一覧（SBOM）の提出義務：システムを構成するOS・ミドルウェア・OSS・ライブラリの一覧が納品物に含まれ、変更時に更新される定めがあるか。
2. パッチ適用の責任分界：脆弱性情報の収集・影響判定・適用作業・適用判断のそれぞれを、発注側とベンダーのどちらが担うか明記されているか。
3. 深刻度別の対応SLA：Critical／High／Medium以下といった深刻度区分ごとに、影響報告と適用完了の目安期間が定められているか。
4. 費用の扱い：通常パッチは月額保守の範囲か、都度見積か。緊急対応の単価や上限、事前承認の要否が決まっているか。
5. EOL（サポート終了）の事前通知義務：使用部品のサポート終了をベンダーが把握し、期限の一定期間前に更改提案とともに通知する定めがあるか。
6. 緊急時の連絡体制：深刻な脆弱性や侵害兆候の際の連絡窓口・手段・受付時間・エスカレーション経路が双方向で決まっているか。
7. 検証環境と適用手順：パッチを本番に当てる前に動作確認する環境の有無と、業務停止を伴う場合の調整手順が定められているか。
8. 適用結果の報告義務：いつ・どのシステムに・何を適用したかの記録が報告され、発注側の手元に残る仕組みがあるか。
9. 脆弱性起因の障害の扱い：パッチ未適用に起因する障害・事故が起きた場合の責任の整理（免責条件を含む）が書かれているか。
10. 契約終了時の引き継ぎ：解約・ベンダー変更の際に、構成情報・アカウント・ソースコード・ドキュメントを引き継ぐ義務と形式が定められているか。

この10項目が契約書上すべてそろっているケースは、中小企業の保守契約ではまれだろう。ゼロでも悲観する必要はないが、少なくとも1（SBOM）・2（責任分界）・5（EOL通知）の3つがない契約は、「保守」という名前の問い合わせ窓口にすぎない可能性が高い。契約更新のタイミングを待たずに、まずベンダーと認識合わせの場を持つことを勧める。誠実なベンダーであれば、責任範囲が明確になることはむしろ歓迎される話であり、この会話を嫌がるかどうか自体が相手を見極める材料になる。

なお、これから新しくシステムを作る場合は、要件定義の段階でこの10項目を組み込むのが最も安い。後から契約に足すより、システム開発の発注時に運用・保守まで設計に含めるほうが、交渉力もコストも圧倒的に有利だ。

よくある質問（FAQ）

Q1. 深刻度がLowなら、結局なにもしなくてよいのでは？ 「確認した結果、急がないと判断する」ことと「何もしない」は違う。今回の2件は、該当構成でなければ影響は限定的で、悪用も公表時点で未確認だから、次回の定期メンテナンスでの適用計画で十分な場合が多い。ただしそれは、自社のどこでTomcatが動いていて、該当構成かどうかを確認できた会社だけが下せる判断だ。確認手段がないまま「Lowだから放置」を選ぶのは、判断ではなく思考停止である。

Q2. 保守ベンダーに影響を問い合わせたが「調べて回答します」のまま1週間返事がない。どう考えるべきか？ それ自体が重要な診断結果だ。原因はおおむね、契約に脆弱性対応が含まれておらず優先順位が上がらないか、ベンダー側も構成を即答できる資料を持っていないかのどちらかで、いずれも今回のLowでは実害がなくても、Critical級では致命傷になる。督促と並行して、回答期限を切った書面照会に切り替え、次回の契約協議でSLA（前章の3）と報告義務(8)を議題にすべきだ。

Q3. IT担当が実質いない。ソフトウェア資産台帳の整備など現実的に可能か？ 最初から完全なSBOMを目指す必要はない。第一歩は表計算1枚でよく、行は業務システム、列は「システム名／構築ベンダーと保守契約の有無／サーバーの場所／主要な中身（ベンダー照会の回答をそのまま貼る）」の4つで足りる。この1枚があるだけで、脆弱性公表の日の初動が「全ベンダーに闇雲に聞く」から「該当しそうな2社に聞く」に変わる。埋まらない欄こそが発見であり、「中身を誰も知らないシステム」の存在が可視化されたなら、それが台帳整備の最大の成果だ。

Q4. クラウドやSaaSを使っていれば、この問題は関係ないか？ SaaSとして提供されるサービスの基盤部分は事業者側の責任で更新されるため、利用企業がTomcatのパッチを意識する必要は基本的にない。ただし、IaaS上に自社（または外注先）が構築したシステムは、仮想マシンの中身のパッチは自社側の責任だ。「クラウドだから安心」の一言で済ませず、責任共有の線がどこに引かれているかをサービス形態ごとに確認してほしい。

GXOに相談すべきサイン

次のいずれかに当てはまるなら、体制の穴が既に開いている状態であり、第三者を入れて棚卸しする価値がある。

• 本稿の「3つの問い」に、どれ一つ30分で答えられなかった
• 保守契約チェックリスト10項目のうち、明文化されていたのが3項目以下だった
• ベンダーへの影響照会に対し、期限内に実質的な回答が返ってこなかった
• サポート終了済みの部品（Tomcat 8.5系以前など）で動いているシステムが見つかった、あるいは見つかりそうで確認が怖い
• 構築ベンダーが廃業・疎遠になり、中身を聞ける相手がいないシステムがある

GXOでは、こうした状態の会社に対して、外部公開面と業務システムの構成を第三者の目で洗い出すセキュリティ診断を入口として提供している。診断で「中身を誰も知らないシステム」が見つかった場合は、脆弱性情報の仕分けからパッチ判断までを継続的に肩代わりするセキュリティ顧問（リテイナー）で平時の体制を作るか、更改期を迎えたシステムなら保守条項を最初から織り込んだシステム開発・再構築で根本から解消するか、状況に応じた道筋を提案できる。ベンダーとの保守契約の見直し交渉に、発注側の立場で同席するセカンドオピニオン型の関わり方も可能だ。

繰り返すが、今回のTomcatの公表自体は静かな事案である。だからこそ、慌てずに自社の体制を測る材料に使ってほしい。次に来るのがLowである保証は、どこにもない。「うちにあるか」を即答できる会社になるための最初の一歩として、まずは無料相談で現状を話すところから始めてもらえればと思う。

参考ソース

• JVNVU#95286373「Apache Tomcatにおける複数の脆弱性」（2026-07-16掲載） https://jvn.jp/vu/JVNVU95286373/
• Apache Tomcat 11.x Security（CVE-2026-59083／CVE-2026-59084、Fixed in 11.0.24） https://tomcat.apache.org/security-11.html
• Apache Tomcat 10.x Security（Fixed in 10.1.57） https://tomcat.apache.org/security-10.html
• Apache Tomcat 9.x Security（Fixed in 9.0.120） https://tomcat.apache.org/security-9.html
• Apache Tomcat 8.5.x EOLアナウンス（2024年3月31日でサポート終了） https://tomcat.apache.org/tomcat-85-eol.html
• JVN#65294474「Tera TermのTTSSH2プラグインにおける複数の脆弱性」（2026-07-16掲載） https://jvn.jp/jp/JVN65294474/
• JVNVU#98998987「JavaScriptライブラリ『Forge』における複数の署名検証不備の脆弱性」（2026-07-16掲載） https://jvn.jp/vu/JVNVU98998987/
• JVNVU#90340653「Pegatron製Windows Driver Model (WDM) ドライバー『Tdelo64.sys』における複数の脆弱性」（2026-07-16掲載） https://jvn.jp/vu/JVNVU90340653/
• JVNVU#90338324「一部のHTTP/2サーバーにおけるフロー制御に起因したサービス拒否（DoS）の脆弱性」（2026-07-17掲載） https://jvn.jp/vu/JVNVU90338324/

※本記事の脆弱性情報は2026年7月18日（執筆時点）の一次情報に基づく。深刻度評価・悪用状況・修正版は更新されることがあるため、対応判断の際は必ず上記の一次情報の最新版を確認してほしい。