tomcat-check

Find out the Tomcat version you actually have installed, and for every 2026 CVE give both rating systems and trigger conditions at the same time.

A zero-dependency single jar — runs offline, no network, nothing uploaded.

What it solves

1. The embedded Tomcat version of a Spring Boot project isn't in your pom.

It is governed by the tomcat.version property of spring-boot-starter-parent; in your pom you only see spring-boot-starter-web. So this tool scans build artifacts (jar / fat jar / installation directory) instead of reading the pom.

2. Some entries can't make it into Dependabot alerts.

Tomcat published 29 CVEs in 2026, some of which won't appear in Spring Boot project alerts due to two mechanisms:

Net effect: a Spring Boot app with embedded Tomcat 9.0.118 shows an all-green Dependabot dashboard, yet this tool reports 4 hits, one of which is exposed by default configuration.

3. The two rating systems use different criteria, and you only get to see one of them.

Of the 29 entries, 17 differ by 2 or more levels between the two rating systems; the most extreme is CVE-2026-41293: official Low, GitHub critical CVSS 9.8.

Nobody got it wrong. After all, the two systems measure fundamentally different things. But to decide "should I upgrade right now", you need to see both — and whether you've enabled that feature.

Usage

java -jar tomcat-check.jar <jar or directory> ...

  --all     also list entries marked "not applicable"
  --utf8    add this if Chinese characters are garbled on the Windows console

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

# Standalone Tomcat installation
java -jar tomcat-check.jar /opt/tomcat

# Entire dependency directory
java -jar tomcat-check.jar target/lib

Requires Java 17+.

What's in the output

Each hit gives you: both rating systems, trigger conditions, the original official description, and whether this entry will show up in your Dependabot alerts. Finally, it gives an upgrade target covering all hits.

🔴 How to read its output

• "Hit" = your version falls within the official Affects range — not "exploited", and not "necessarily exploitable". Only a few of the 29 entries are exposed by default configuration; the rest require you to explicitly enable some feature (RewriteValve, DIGEST authentication, AJP, WebDAV, cluster communication…). Check the trigger conditions one by one.
• "Dependabot won't alert" doesn't mean GitHub failed. unreviewed is a normal pipeline status.
• The judgment table only covers CVEs published in 2026. No hits doesn't mean your version is free of problems.
• The tool won't decide for you whether to upgrade — it gives you the three things needed to make that decision: which version you have installed, how the vendor rates it, and what the trigger conditions are.

Where the judgment table comes from

tools/gen_rules.py generates CveTable.java from two primary sources — not a single line hand-copied:

• https://tomcat.apache.org/security-{9,10,11}.html — official ratings, titles, original descriptions, affected ranges
• GitHub Advisory API — GitHub ratings, CVSS, type, affected Maven coordinates

The generation process carries 7 assertions; if any one fails, it aborts and writes no file. Three of them are worth calling out:

• ASSERT7 (parse completeness): count the entries a second time with an independent regex method; the two sets must be exactly identical. The origin is a very subtle kind of mismatch — some titles on the official page embed a link to another CVE: <strong>Moderate: The fix for <a>CVE-2025-66614</a> was incomplete</strong> <a>CVE-2026-32990</a>. Searching the whole block for the "first CVE" picks up that old ID embedded in the title; the consequence isn't a missing entry — it's a case of mistaken identity: one CVE ends up carrying another's title and description, while generation, tests, and verification against real artifacts all pass exactly as normal.
• ASSERT3 (pairing direction): on the official page, the Affects: line sits right next to the next CVE's title, making it extremely easy to pair it with the wrong one — a mistake yields a table that "looks perfectly normal but is shifted by one slot as a whole". Cross-validated against GitHub's first_patched_version; during development it really did catch such a misalignment once.
• ASSERT6 (exclusion justification): download the real jars from the 9.0 / 10.1 / 11.0 lines, and confirm one by one that the code of the excluded entries (cluster components, FFM connector, sample applications) is indeed absent from tomcat-embed-*. The exclusion basis must come from actual verification, not "as I remember".

To regenerate:

python tools/gen_rules.py

Build

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

34 tests. Zero dependencies at runtime; JUnit is test-only.

License

MIT