tomcat-check

実際にインストールされている Tomcat のバージョンを特定し、2026 年の各 CVE について 2 つの評価とトリガー条件を同時に提示します。

依存関係ゼロの単一 jar、オフラインで動作し、ネットワーク接続せず、何もアップロードしません。

これが解決するもの

1. Spring Boot プロジェクトの組み込み Tomcat バージョンは、pom にはありません。

これは spring-boot-starter-parent の tomcat.version プロパティで管理されており、pom には spring-boot-starter-web しか見えません。そのため、このツールはビルド成果物(jar / fat jar / インストールディレクトリ)をスキャンし、pom は読みません。

2. Dependabot のアラートに載らないエントリがあります。

2026 年に Tomcat は 29 件の CVE を公開しましたが、その一部は 2 つの仕組みにより Spring Boot プロジェクトのアラートには表示されません:

実際の効果:Tomcat 9.0.118 を組み込んだ Spring Boot アプリケーションで、Dependabot パネルが全て緑でも、このツールは 4 件のヒットを報告します。そのうち 1 件はデフォルト設定で露出します。

3. 2 つの評価体系は基準が異なるのに、あなたが見られるのはそのうちの 1 つだけです。

29 件のうち 17 件は 2 つの評価が 2 段階以上異なります。最も極端なのは CVE-2026-41293:公式は Low、GitHub は critical CVSS 9.8 です。

これは誰かの報告が間違っているわけではありません。 2 つの体系は元々異なるものを測定しています。 しかし「今すぐアップグレードすべきか」を判断するには、両方を同時に見る必要があります —— そして、その機能を有効にしているかどうかも。

使い方

java -jar tomcat-check.jar <jar 或目录> ...

  --all     连「不适用」的条目也列出来
  --utf8    Windows 控制台中文乱码时加这个

# Spring Boot fat jar
java -jar tomcat-check.jar target/my-app.jar

# 独立安装的 Tomcat
java -jar tomcat-check.jar /opt/tomcat

# 整个依赖目录
java -jar tomcat-check.jar target/lib

Java 17 以降が必要です。

出力に含まれるもの

各ヒットについて、2 つの評価、トリガー条件、公式の説明原文、およびこのエントリがあなたの Dependabot アラートに表示されるかどうかを示します。最後に、すべてのヒットをカバーできるアップグレード先を示します。

🔴 出力はこう読んでください

• 「ヒット」= あなたのバージョンが公式の Affects 範囲内にあることであり、「悪用済み」や「必ず悪用可能」という意味ではありません。 29 件のうち少数のみがデフォルト設定で露出し、残りは何らかの機能(RewriteValve、DIGEST 認証、AJP、WebDAV、クラスタ通信……)を明示的に有効にする必要があります。トリガー条件を 1 件ずつ確認してください。
• 「Dependabot がアラートを出さない」ことは GitHub の怠慢を意味しません。 unreviewed は正常なプロセス状態です。
• 判定表は 2026 年に公開された CVE のみをカバーします。 ヒットがなくても、あなたのバージョンに問題がないとは限りません。
• このツールがアップグレードすべきかどうかを代わりに決定することはありません —— 提供するのは、その判断に必要な 3 つの情報です: インストールされているバージョン、公式の評価、そしてトリガー条件です。

判定表の生成方法

tools/gen_rules.py は2 つの一次情報源から CveTable.java を生成し、1 行も手書きしません:

• https://tomcat.apache.org/security-{9,10,11}.html —— 公式の評価、タイトル、説明原文、影響範囲
• GitHub Advisory API —— GitHub の評価、CVSS、type、影響を受ける Maven 座標

生成プロセスには 7 つのアサーションが含まれており、いずれかが満たされない場合は中止され、ファイルは書き込まれません。そのうち 3 つは特に言及する価値があります:

• ASSERT7(解析の完全性):2 つ目の独立した正規表現の基準でエントリを数え直し、両方の集合が完全に一致することを確認します。 由来は非常に分かりにくいタイプの誤対応です —— 公式ページの一部のタイトルには別の CVE のリンクが埋め込まれています: <strong>Moderate: The fix for <a>CVE-2025-66614</a> was incomplete</strong> <a>CVE-2026-32990</a>。 ブロック全体から「最初の CVE」を探すと、タイトルに埋め込まれた古い番号が取得され、結果は「1 件不足」ではなく取り違えです: ある CVE に別の CVE のタイトルと説明が結び付けられ、しかも生成、テスト、実物の成果物による再検証がすべて通常どおり成功します。
• ASSERT3(ペアリングの方向):公式ページでは Affects: 行が次の CVE のタイトルの直後にあり、誤ったエントリとペアリングされやすいのです —— 間違うと「一見まったく正常だが全体が 1 つずれた」表になります。 GitHub の first_patched_version で相互検証しており、開発中に実際にこれで 1 回ずれを検出しました。
• ASSERT6(除外の根拠):9.0 / 10.1 / 11.0 の 3 つのラインの実物 jar をダウンロードし、除外されるエントリ(クラスタコンポーネント、FFM コネクタ、サンプルアプリ)のコードが tomcat-embed-* に実際に存在しないことを 1 つずつ確認します。 除外の根拠は実測でなければならず、「記憶に基づく」ではいけません。

再生成:

python tools/gen_rules.py

ビルド

mvn clean package     # → target/tomcat-check.jar

34 個のテスト。実行時の依存関係はゼロで、JUnit はテスト時のみです。

ライセンス

MIT