What is Apache Tomcat Vulnerabilities: Detection, Fixes & Tips

Key Takeaways

• Most Tomcat risk comes from known, unpatched CVEs on old or end-of-life builds.
• High-impact flaws like CVE-2025-24813 and Ghostcat need specific risky settings to fire.
• Detection starts with knowing every Tomcat version you run and which risky settings are on.
• Upgrade where you can, mitigate in config where you cannot, and never leave EOL builds exposed.

A team enables write access on Tomcat’s default servlet to support a file upload feature, ships it, and moves on. What they miss is that partial PUT is on by default, so one of the preconditions behind CVE-2025-24813 is now sitting there. If that application also uses Tomcat’s file-based session persistence at the default storage location, and it happens to ship a library that can be abused for deserialization, the result is unauthenticated remote code execution. CISA has had it in the Known Exploited Vulnerabilities catalog since April 1, 2025.

That is the recurring pattern behind Tomcat incidents. Rarely a clever new attack. Usually a known issue left running on an old build, or a risky setting nobody went back to review.

This guide walks through the risks, the CVEs worth knowing, and how to detect, patch, and harden your servers.

What Are the Risks of Apache Tomcat Vulnerabilities?

Tomcat is one of the most widely deployed Java servlet containers, which makes it a standing target. When a flaw lands, the blast radius is rarely just one server.

The worst case is remote code execution, where an attacker runs arbitrary commands on the host. A step below that is information disclosure, where files like web.xml, source code, or config secrets get read without authentication. Then there is content injection, where malicious data lands in uploaded files or session data. And any compromised Tomcat instance makes a convenient foothold for lateral movement into the rest of the network.

Reality Check: “We upgraded, so we are fine” falls apart if some instances run an end-of-life branch. Tomcat 8.5 hit upstream end of life on March 31, 2024, and never received an upstream fix for CVE-2025-24813. Without a vendor supplying post-EOL patches, those servers stay exposed no matter how many other boxes you patched.

Common Apache Tomcat Vulnerabilities

Tomcat CVEs cluster around a handful of themes. Unsafe request handling, protocol trust, path resolution, authentication logic, and insecure crypto defaults cover most of them. Here are the ones worth knowing, with the affected and fixed versions Apache publishes.

CVE-2025-24813 (Partial PUT RCE)

This one pairs a path equivalence bug with unsafe deserialization, and the preconditions are specific but entirely realistic. Writes have to be enabled on the default servlet, which is off by default. Partial PUT has to be on, which it is by default.

The application has to use Tomcat’s file-based session persistence at the default storage location. And the application has to include a library that can be abused in a deserialization attack. Line all four up and an attacker can stage a serialized payload with a partial PUT, then trigger execution with a follow-up request carrying the matching JSESSIONID.

It went public on March 10, 2025, and CISA added it to the Known Exploited Vulnerabilities catalog on April 1, 2025.

CVE-2020-1938 (Ghostcat)

Ghostcat is a file read and inclusion flaw in the AJP connector, which historically shipped enabled on port 8009 and bound to every configured address. A remote, unauthenticated attacker who could reach that port was able to return arbitrary files from anywhere in the web application, including under WEB-INF and META-INF, and have Tomcat process any file in the application as a JSP. It escalates to code execution when the application also stores uploaded files inside the web application. The fixes landed in 7.0.100, 8.5.51, and 9.0.31, which is also where Apache commented the connector out of the default server.xml, moved its default bind address to loopback, and made an AJP secret mandatory. It has been on the KEV catalog since March 3, 2022.

CVE-2025-55752 (Directory Traversal)

A regression in the Rewrite Valve normalized rewritten URLs before decoding them. Where rewrite rules move query parameters into the URL, an attacker could manipulate the request URI to slip past the protections on /WEB-INF/ and /META-INF/, with code execution on the table if PUT was enabled as well. Apache notes that combination is unlikely, since PUT is normally restricted to trusted users, but the case is still worth reading. It shows how a fix in one release can quietly reintroduce risk in another.

CVE-2026-29146 (EncryptInterceptor Padding Oracle)

A good reminder that a default setting can be the vulnerability. The EncryptInterceptor, used to encrypt cluster traffic, defaulted to CBC mode, which is open to padding oracle attacks. Any deployment running that interceptor on its default cipher mode was potentially exposed without an administrator having selected anything unusual. For versions covered by TuxCare’s Endless Lifecycle Support, backported fixes are tracked per version in the CVE tracker, which shows exactly which covered releases have the fix available.

CVE-2026-34486 (EncryptInterceptor Bypass)

The fix for CVE-2026-29146 shipped in 9.0.116, 10.1.53, and 11.0.20, and it carried an error that let the EncryptInterceptor be bypassed entirely. Note the Tomcat 11 number there. The fix was written for 11.0.19, but that release vote failed, so 11.0.20 was the first build anyone could actually download. Exactly those three releases are affected, and 9.0.117, 10.1.54, and 11.0.21 close it. CISA added this one to the KEV catalog on August 4, 2026, so a cluster upgrade that stopped at the first fix is not finished.

CVE-2026-55957 (GSSAPI Auth Bypass)

When JNDIRealm was configured to authenticate binds using GSSAPI, an attacker could authenticate without the correct password. No brute force, no stolen credentials. The authentication logic simply failed to enforce the check. The timeline is the strange part. The fix quietly shipped in 9.0.102, 10.1.39, and 11.0.5, and the issue was only made public on June 29, 2026, more than a year later. Anything at or below 9.0.100, 10.1.36, or 11.0.4 needs attention. Anything newer was already covered before the CVE had a number.

CVE-2026-43512 (Digest Auth “null” Password)

The failure mode here is almost too simple to believe. Tomcat’s Digest authenticator would accept the literal string “null” as a valid password for any username that did not exist in the configured Realm. So a user who is not in the system could authenticate by guessing that one string. The blast radius depends on what sits behind Digest auth, but the precondition is trivial to meet. It was made public on May 12, 2026, and fixed in 9.0.118, 10.1.55, and 11.0.22.

Did You Know: In March 2025, Palo Alto Networks blocked 125,856 scans, probes, and exploit attempts tied to CVE-2025-24813 and two related Apache Camel flaws, originating from more than 70 countries, within three weeks of disclosure.

How to Detect and Assess Apache Tomcat Vulnerabilities

Detection is mostly an inventory problem. You cannot patch what you have not found, and larger estates have a habit of accumulating Tomcat instances that never made it onto any list. Work through these three steps in order.

Inventory every instance and version

Find every Tomcat deployment, including applications that embed it, such as Spring Boot applications running the embedded Tomcat server. Record the exact version, not the folder name. Installs get copied and renamed, so the path lies.

Pro Tip: Run the bundled version script rather than guessing from the install path. $CATALINA_HOME/bin/version.sh prints the exact Tomcat and JVM versions, which is the data you need for any real assessment.

Map versions to known CVEs

Cross-reference each version against the NVD, the Tomcat security advisories for your branch, and CISA’s KEV catalog. Anything on KEV should be treated as actively exploited and moved to the front of the queue.

Check the risky configuration flags

Several Tomcat CVEs only bite when specific settings are on. Confirm whether the default servlet has readonly set to false, whether allowPartialPut is enabled, whether the AJP connector is reachable, and whether JNDIRealm, Digest auth, or the EncryptInterceptor are in play at all. That configuration picture is what separates a CVE that is merely present from one that is genuinely exploitable.

How to Fix and Patch Apache Tomcat Vulnerabilities

Patching Tomcat is usually straightforward when a fixed release exists. The hard part is the servers where upgrading is blocked, or where the version is already end of life.

Upgrade to a patched release

For actively maintained branches, move to a fixed version, and treat the per-CVE numbers in the table above as the floor rather than the destination. Land on the latest release in your branch, which today means 9.0.121, 10.1.59, or 11.0.25. Stopping at the minimum fix for one CVE leaves you carrying everything published since. CVE-2026-29146 is the cautionary example. Its initial fixes shipped in 9.0.116, 10.1.53, and 11.0.20, and all three of those releases turned out to be vulnerable to the patch bypass CVE-2026-34486, so the real floor there is 9.0.117, 10.1.54, or 11.0.21.

TuxCare’s CVE Tracker for Apache Tomcat is handy for checking which CVEs affect a specific older or EOL version.

Apply config mitigations when you cannot upgrade yet

If a version bump has to wait, cut the exploit path off at the config layer. Keep readonly set to true on the default servlet, which is the default and which removes the writable-servlet precondition on its own. If writes are genuinely required, set allowPartialPut to false wherever the application does not need partial uploads. That parameter has been around for years, including on 8.5.100 and the older 9.0 builds, so it is a real option on unpatched servers. Then disable the AJP connector if you do not use it, or bind it to the interface your proxy actually needs and give it a secret if you do.

Watch Out: Partial PUT is enabled by default, but file-based session persistence is not, and neither is a writable default servlet. The moment someone flips the default servlet to writable for a file upload feature, one of the non-default preconditions is in place. Add file-based session persistence at the default storage location and a library that can be abused for deserialization, and the full CVE-2025-24813 chain is live. Treat “enable writes” as a security decision rather than a convenience toggle, and audit for the other two conditions while you are in there.

Choose manual or automated patching and cover EOL versions

How you patch depends on fleet size, how much change control you have to satisfy, and whether the version still receives upstream fixes.

Tomcat is a fairly self-contained servlet container, and most advisories land on its own components such as Catalina, Coyote, and Jasper. Production deployments still need to track the JDK and any libraries the application bundles, since those dependencies carry vulnerabilities of their own. In a case like CVE-2025-24813, a bundled library is also what supplies the gadget chain that turns unsafe deserialization into code execution.

When upstream fixes stop reaching the build you are actually running, that is where TuxCare’s Endless Lifecycle Support for Apache Tomcat comes in. It backports CVE fixes into pinned Tomcat releases, delivered from a TuxCare repository, so you can stay where you are instead of taking a version jump you have not tested. Coverage currently spans selected Tomcat 7, 8.5, 9.0, and 10.1 releases, namely 7.0.109, 8.5.100, 9.0.46, 9.0.50, 9.0.75, 9.0.83, 9.0.87, 9.0.90, 9.0.100, 10.1.18, and 10.1.42, and the documentation carries the current matrix. That range matters because the problem is not only the branch end of life. Tomcat 7 and 8.5 are both long past it, 8.5 since March 31, 2024, and Tomcat 9.0 has now had its end of support announced for March 31, 2027. But an application pinned to an older 9.0 or 10.1 release does not receive the fixes Apache adds in later releases of that same branch.

The short version is that if your Tomcat version still gets upstream patches, upgrade on a set cadence. If it is end of life, or pinned somewhere upstream has moved past, go with vendor-backed patching or plan the migration. Running it unpatched is not one of the options.

Best Practices for Securing Apache Tomcat

Hardening Tomcat is less about exotic controls and more about keeping the safe defaults intact, switching off what you do not use, and tightening whatever you do expose. A few consistent habits close most of the common holes.

Stay on supported versions

Keep both Tomcat and the JDK on releases that still receive security fixes. For builds that upstream has left behind, Endless Lifecycle Support for Apache Tomcat keeps patches flowing without a forced migration.

Lock down connectors and the default servlet

Apply least privilege to Tomcat’s exposed surface. Leave the default servlet read-only unless you have a hard reason not to, disable partial PUT if you do not use it, and never leave AJP reachable from untrusted networks.

Insider Tip: If you use AJP, bind the connector to the interface your trusted proxy actually needs, restrict access to it at the network layer, and set a secret. Ghostcat was as dangerous as it was largely because that port sat open on default installs for well over a decade.

Put Tomcat behind a reverse proxy and monitor it

For most production deployments, put a hardened reverse proxy in front of Tomcat rather than exposing the application connector directly. Remove the sample applications, and tightly restrict access to the manager application if you keep it. Watch access logs for unusual file requests, particularly anything probing /WEB-INF/ or throwing unexpected PUT requests.

Keep Your Apache Tomcat Protected with TuxCare

Apache Tomcat vulnerabilities rarely announce themselves. They sit quietly in default configs and end-of-life versions until someone scans your server. The fix is boring but reliable. Know what you run, patch what has a fix, mitigate what does not, and never leave an EOL build exposed. If you are stuck on a release upstream no longer supports, see how TuxCare delivers Endless Lifecycle Support for Apache Tomcat.

Summary

Article Name

What is Apache Tomcat Vulnerabilities: Detection, Fixes & Tips

Description

Keep your Apache Tomcat servers safe! Learn to spot vulnerabilities, patch them, and follow best practices for strong security.

Author

Rohan Timalsina

Publisher Name

TuxCare

Publisher Logo