Apache Tomcat Vulnerabilities, October 2026: 8 Flaws and Fixes

On 20 October 2026, eight vulnerabilities were published in Apache Tomcat, software that runs web applications. The next day, the 21st, JVN also covered them as "JVNVU#93110597". The fixed versions are 11.0.27, 10.1.61 and 9.0.123.

This article is for companies with business systems built in Java. It explains which versions are affected, how the impact changes depending on your configuration, and how to update. Tomcat is often built into packaged products and Spring Boot applications, so even companies that think "we don't use it" should check.

What are the vulnerabilities, and which should you deal with first?

The three more serious issues are as follows. None of them occurs on every Tomcat; the impact depends on the version and configuration.

In the server.xml bundled with Tomcat, the AJP connector and the HTTP/2 settings are commented out. In other words, with the default settings, the AJP and HTTP/2 problems do not come into play. However, quite a few companies have changed these settings and use them. Don't decide "not affected" without looking at your own configuration.

The remaining five are rated "Low" by Apache.

• CVE-2026-93446: TLS 1.3 connections can sometimes fail
• CVE-2026-88041: HTTP/2 trailer information gets mixed into the next request
• CVE-2026-74049: After <c:redirect> in a JSP, the rest of the page continues to be processed
• CVE-2026-74048: Even if enabling FIPS mode fails, Tomcat still starts up
• CVE-2026-80353: An issue with permission settings for UNIX domain sockets (listed under the 9.0 branch)

Affected versions and where to move

※ Support for the 8.5 branch ended on 31 March 2024. According to the CVE records, CVE-2026-101296 and CVE-2026-74049 also affect the 8.5 and 7.0 branches.

※ If you are on the 9.0 branch, it will be easier to plan your next steps if you also check Apache's plans for the 9.1 branch.

Five steps to check and respond

1. Find out where Tomcat is running

   As well as copies installed directly on servers, check those built into packaged products, Docker images and Spring Boot applications (tomcat-embed-core).

2. Check the version

   On a server, you can check with bin/version.sh (version.bat on Windows). If it is built into an application, look at the dependencies at build time.

3. Check the configuration

   In server.xml and similar files, check whether the JNDIRealm authentication method, HTTP/2 (UpgradeProtocol) or an AJP connector is in use.

4. Try the update in a test environment

   An update within the same branch has a relatively small impact. Try the main functions, such as login, file upload and connections with outside systems, before applying it to production.

5. Check the Java version too

   While updating Tomcat, review your Java version as well. See also "Java Vulnerabilities, October 2026".

If you can't update right away

Apache's notices give updating to the fixed version as the response. Until you update, you can reduce the risk by stopping the affected functions. To fix the problem properly, you need to update.

• If you don't use AJP, disable the connector. If you do use it, make sure it cannot be reached from outside
• If you don't need HTTP/2, remove the UpgradeProtocol setting
• If the LDAP integration settings apply to you, set a date for the update as a priority

For companies with old Java systems

Systems with an outdated Tomcat often have an outdated Java and OS too. If you can't update everything at once, review the parts exposed to the internet first. The approach is explained in "Securing Legacy Systems: Where to Start", and if you can't reach your development company, see "Taking Over a Legacy System With No Documentation".

Questions for your contractors

• What version of Tomcat is our system on now? Have the fixes published in October been applied?
• Is a separate copy of Tomcat built into any of the applications or packages?
• Do we use LDAP integration, HTTP/2 or AJP?
• Are Tomcat updates included in the maintenance contract?

Leave it, or act now?

How Digi Dinos can help

Digi Dinos is a company that supports DX, security, and the operation and maintenance of systems. We have offices in Japan and Vietnam, and over the 8 years since our founding we have delivered more than 150 projects. We are ISO 27001 certified, and our team works in Japanese.

• Java and Tomcat updates: from checking versions and configuration to testing and applying the update to production.
• Taking over maintenance of old systems: we also read and investigate the code of systems built by other companies, and take them over.
• Migration planning: we propose how to move from an unsupported version, together with the cost and timeline.
• Lifetime warranty: if a defect turns up in work we did, we take responsibility and fix it, with no time limit for as long as the maintenance contract continues.

Frequently asked questions