Apache Tomcat Marks Dead Versions “Unknown” — and Your Scanner Reads That as Clean

By Scott Bissett  ·  Published August 27, 2026  ·  Verified against Apache Tomcat's security pages, the published CVE record for CVE-2025-24813, CISA's KEV catalog, and the Apache Tomcat release record

There is a paragraph on Apache Tomcat's own security pages that explains, better than any security-vendor pitch ever could, why vulnerability scanners keep giving dead Tomcat installations a clean bill of health. It is not hidden. It is stated policy, in plain text, on the page most people scroll past on their way to the CVE tables:

“The published CVE records for vulnerabilities reported from 2023 onwards include affected version information for EOL versions. By default, the status for EOL versions is reported as unknown.”

And two sentences later, the part that should change how you read every scan report you have ever run against an old Tomcat: the security page “will NOT be updated if the status of an EOL version is updated” — and no email announcement is made either. Once a Tomcat version line dies, Apache stops evaluating it, defaults its status on new CVEs to unknown, and never revisits the page you would check.

To be clear about who is at fault here: not Apache. This is unusually honest vendor behavior — the policy is documented, the wording is precise, and evaluating vulnerabilities against versions nobody maintains is real work the project explicitly declines to promise for free. The failure happens downstream, in every tool and every review that treats “no known vulnerabilities” as if it meant “known to have no vulnerabilities.”

Key Dates at a Glance

• tomcat 10.0: end of life 2022-10-31
• tomcat 9.0: end of life 2027-03-31
• tomcat 8.5: end of life 2024-03-31
• tomcat 8.0: end of life 2018-06-30
• tomcat 7: end of life 2021-03-31

What the Policy Looks Like on a Real, Actively Exploited CVE

This is not a theoretical concern. Take CVE-2025-24813 — the Tomcat partial-PUT flaw that Apache titles “Potential RCE and/or information disclosure and/or information corruption”, and which sits on CISA's Known Exploited Vulnerabilities catalog, meaning it has been exploited in the wild. The machine-readable CVE record, published by Apache's own CNA, lists version status like this:

Read the bottom half of that table again. For a vulnerability confirmed to be exploited in the wild, the official status of the entire Tomcat 10.0 line — and of every version line from Tomcat 3 through 8.0, roughly two decades of releases — is a documented shrug. In this particular record Apache went further than its default and marked 8.5 as affected, which is exactly the honesty the policy allows for: “Where additional information is available, the published CVE record may be updated.” But 10.0 and everything older stayed at the default. Nobody evaluated them. Nobody will.

Why Scanners Turn “Unknown” Into “Fine”

Vulnerability scanners and software-composition tools overwhelmingly work by matching your installed version against the affected-version metadata in published CVE records. If the record says a version range is affected, you get a finding. If the record says unknown — or says nothing at all, as with vulnerabilities reported after Apache stopped listing them for a dead line — most tools emit nothing. There is no “this version stopped being evaluated” severity level. The dashboard shows green.

Which produces the perverse outcome every asset owner should sit with for a moment: the older and deader your Tomcat, the cleaner it looks. A patched, supported Tomcat 9 install accumulates findings every quarter because someone is actively evaluating it. A Tomcat 8.0 install — end of life since June 30, 2018 — accumulates silence. The reporting gradient runs exactly backwards from the risk gradient.

The Corollary: Every “N CVEs Affect Old Tomcat” Number Is an Estimate

There is a second consequence of Apache's policy that cuts the other way, against the security industry's marketing habits. Because Apache does not evaluate EOL versions, no vendor-published count of vulnerabilities affecting an end-of-life Tomcat line exists — for any line, in any direction. When a scanner vendor, a support vendor, or an article (including ours) wants to say “this many CVEs hit EOL Tomcat 8.5,” that number is necessarily the result of somebody's own analysis: their guess at which post-EOL CVEs would have applied. Some of those analyses are careful. None of them are Apache's. We do not publish such counts, and when you see one, the right question is “evaluated by whom, against what?”

What can be stated from primary sources is smaller and harder: the policy itself, the per-CVE records where Apache chose to fill in an EOL version's status — and the lifecycle dates. Those we track and verify.

The Tomcat Support Map

The lifecycle facts, from the Tomcat product page we verify against Apache's own announcements. Note the EOL notice Apache attaches to the 8.x security page: “Tomcat 8.5.x has reached end of life and is no longer supported. Vulnerabilities reported after 31 March 2024 are not listed below and will not be fixed. Users should upgrade to 9.0.x or later to obtain security fixes.”

The risk picture per line is live on the product page — 80 is Tomcat 8.5's current EOL Risk Score, recalculated at every build from EOL recency, attack surface, CISA KEV exposure, and extended-support availability; the full Tomcat page carries the rest. Our derivation of CISA's live KEV catalog currently attributes six actively-exploited entries to Tomcat — exposure that a scanner reading “unknown” as “clean” will never surface for a dead line.

What To Do, In Order

1. Find your versions. Tomcat prints its version in server logs at startup, in the manager app, or via version.sh / version.bat in the bin directory. Inventory every instance — the forgotten ones are the point of this article.
2. Treat any 8.5, 10.0, 8.0, or 7 install as unevaluated, not clean. Whatever your scanner says about it, the vendor's position is that nobody is checking. The honest severity of “unknown” on an internet-facing service is closer to “assume affected” than “no findings.”
3. Upgrade to a supported line. Apache's stated destinations are 9.0.x or later; 9.0 is supported until March 31, 2027 at the earliest, and 10.1 and 11.0 carry no announced end date. Mind the javax→jakarta namespace change when crossing from 9.0 to 10.1+ — our Tomcat end-of-life guide covers the migration path.
4. If you genuinely cannot move yet, commercial extended-support options exist for end-of-life Tomcat lines — the form above will match you with vetted options, free.

FAQ

Related Reading

• Apache Tomcat end-of-life dates and risk scores — the live lifecycle page
• Apache Tomcat End of Life — every version's dates and the javax→jakarta migration
• When CVSS, EPSS, and KEV Disagree — how the security signals argue, and what to do about it
• The Exploited & Unpatchable feed — KEV-listed CVEs whose only fix is leaving the version you run