tomcat85-check

Still running Tomcat 8.5? This tool tells you exactly which 2025 CVEs you're affected by — because on this question, you can't get a complete answer from the official page, NVD, or scanners.

Zero-dependency single jar, runs offline, no network, uploads nothing.

---

What it solves

Tomcat 8.5 reached EOL on 2024-03-31, with the final release being 8.5.100 (released 2024-03-19). After that, Apache still declared in CVE records, one by one, that "8.5 is affected too" — and that's the place the fewest people look.

The Apache official 9.x security page lists 17 CVE-2025-* entries, of which 14 say verbatim:

The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.x though 8.5.100

(sic — 8 of the 14 misspell through as though; the lower bound is mostly 8.5.0, but also 8.5.6 / 8.5.44 / 8.5.60 / 8.5.90)

For these 14, here's what you see in three different places:

Where you'd look	What you see
Apache official 8.5 security page (security-8.html)	Zero entries for 2025 — the page stops at 2024-02-19 Fixed in Apache Tomcat 8.5.99
NVD	Querying 8.5.100 by cpe, only 4 of the 14 come back; the other 10 have no 8.5 at all in their cpe configuration
GitHub advisory	All 14 are there, but the 8.5 side's first_patched_version is null across the board

The only place that states this completely is the original record Apache submitted as CNA on CVE.org — the layer the fewest people bother to dig through. What this tool does is take that layer's information and lay it out against the version actually installed on your machine.

🔴 This tool states differences between data sources, not the behavior of any product. Whether "your scanner reports these 10" depends on which database it reads and how it merges them — that hasn't been empirically tested, so it won't be written here.

---

The other half that matters just as much: only 2 of the 14 are triggered by default configuration

Reporting by version number alone means calling all 12 "requires specific configuration" entries "you're affected" — that's making you do something unnecessary.

So when given an installation directory, this tool reads all XML under conf/ (including conf/Catalina/<host>/), strips comment blocks, and then looks for the markers of trigger conditions. Stripping comments isn't optional: in the official server.xml, a text search for UpgradeProtocol hits once, but after stripping comments it's 0 — the whole thing is commented out.

Running it against a bare official 8.5.100 gives this:

Affected by default: 2 · Configuration confirmed: 0 · Needs manual confirmation: 11 · Not applicable: 1
Of these, 10 cannot be found for 8.5 in NVD's cpe configuration

With HTTP/2, RewriteValve, and CGIServlet enabled in the same configuration, "Configuration confirmed" becomes 5.

---

Usage

java -jar tomcat85-check.jar <install dir | jar | war> ...

  --all     also list entries whose "version is outside the range"
  --utf8    add this when the Windows console garbles Chinese text

# An unpacked Tomcat deployment — pass the level containing conf/, saves a lot of manual work
java -jar tomcat85-check.jar /opt/tomcat

# A single jar / war can be scanned too
java -jar tomcat85-check.jar /opt/app/lib/catalina.jar

How the version is identified for an unpacked deployment

The jars under lib/ have no version number in their filenames (it's catalina.jar, not catalina-8.5.100.jar). Tools that take the version from the filename alone can't identify a single one on this kind of deployment — and "didn't find anything" looks exactly the same as "you're safe."

This tool takes the version in this order:

1. server.number from catalina.jar!/org/apache/catalina/util/ServerInfo.properties — this is what Tomcat's own version.sh reports
2. Implementation-Version from META-INF/MANIFEST.MF
3. Filename (only present in the Spring Boot embedded form)

When the two sources disagree (ServerInfo.properties can be overridden, often used to hide the version), both are reported, and it won't choose for you.

---

Three lines it won't cross

One, it can confirm enabled, not confirm disabled. When the report says "not found," it means not found in the files I looked at, not "you don't have it enabled." Configuration can appear in places this tool can't see: WEB-INF/web.xml inside a war, an external CATALINA_BASE, startup arguments. So there's no "not affected" tier — anything not found falls into needs manual confirmation.

Two, finding it doesn't always mean it's the one. For example, in the official default server.xml, AprLifecycleListener is enabled by default, but it only attempts to load the native library — when the library is absent, the APR connector isn't enabled. So it's a "weak marker": a hit only reports "possible," not "confirmed."

Three, there's no 8.5 version to upgrade to. The first_patched_version for all 14 is null on the 8.5 side. It's not "not fixed yet," it's "won't be fixed for 8.5." The only way out is to switch lines (9.0 / 10.1 / 11.0). This tool answers "what are you affected by," and doesn't pretend to answer "which 8.5 to upgrade to."

---

One more thing that easily makes you think "the tool reported an error": the same CVE has several ratings

Take CVE-2025-55754 — all four numbers are real:

Who gave it	Value
Apache (ASF four-tier)	low
GitHub advisory	low
CVSS v3.1 (what NVD adopts)	9.6 critical
CVSS v4.0	2.1

If you only look at NVD, you'd think this is the most severe one; if you only look at Apache, you'd think you can ignore it. Neither is wrong — Apache rates actual exploitability under default configuration, while CVSS is mechanically computed from the vector and doesn't care whether you have that feature enabled.

So this tool prints all four numbers, and states it explicitly when the two sides judge differently.

The two vocabularies aren't the same thing; alignment only goes as far as the official support

Apache uses low / moderate / important / critical, GitHub uses low / medium / high / critical. The basis for alignment comes from the original text of Tomcat's official security-impact.html:

Important / High — A vulnerability rated as Important (or High) impact is one which could result in the compromise of data or availability of the server.

→ Important and High are two names for the same tier — the official docs themselves write them together. 🔴 But moderate and medium are not stated by the official docs to be alignable, and this tool won't align them for you — ASF's Moderate defines exploitability conditions like "has significant mitigating factors / doesn't affect common configurations / requires authentication," while GitHub's medium is a CVSS score range; the two aren't the same thing. In such cases it reports "the official docs don't say these two tiers are equal," and lays both out for you.

By this standard, of the 14, 5 are judged substantively differently by the two sides (the furthest being CVE-2025-52520: Apache low / GitHub high), 2 can't be aligned, and 7 are the same.

---

Where the data comes from, and how to reproduce it

The decision table CveTable.java is generated — not a single line is hand-copied:

python -u tools/fetch_sources.py    # pull three primary sources → tools/sources.json
python -u tools/gen_table.py        # generate CveTable.java (5 assertions; if any fails, no file is written)