Apache Tomcat's October 2026 Vulnerabilities Explained: Mixed-Up User Responses

Imagine an order-status page that suddenly shows a stranger's address. Nobody broke in. The server itself handed one person's data to another person's request. That is a response mix-up, and it is what the Apache Tomcat vulnerability October 2026 advisories warn about.

It is hard to spot, because most requests still work and leaked data can look like a normal reply.

Picture a common setup. An order-tracking API is a Spring Boot app, and Spring Boot runs it on an embedded Tomcat server. The setup is made up, but the bug class is real. The team turned on HTTP/2 for speed and used async endpoints that wait for the kitchen system before replying.

The app answers about 2 lakh (200,000) order-status calls a day (made up). Most go fine. After an error during async processing, Tomcat could reuse an internal object too early, and a late reply could land on the next customer's request. This guide follows that API through the advisory, the version check and the upgrade.

You need seven words. Each gets a plain meaning and an example from the order-tracking API.

• Apache Tomcat: an open-source Java web server that runs servlets, the Java classes that handle web requests. Spring Boot web apps include it inside the app as a jar, called embedded Tomcat.
• Connector: the part of Tomcat that speaks one network protocol. The HTTP connector talks to browsers, and the AJP connector talks to a front web server.
• HTTP/2: a newer version of HTTP that sends many requests at once over one connection, each in its own numbered stream. It is turned on only when you configure it.
• AJP: the Apache JServ Protocol, a compact link between a front web server such as Apache httpd and Tomcat. One AJP connection carries many requests, one after another.
• Async servlet: a request that the server parks while slow work runs on another thread, then finishes later. Spring MVC uses it for return types such as DeferredResult and Callable.
• Recycling: Tomcat reuses internal request and response objects instead of creating new ones for every request. This saves memory and time, but an object must be fully cleaned before reuse.
• CVE: a Common Vulnerabilities and Exposures ID, a public name for one security bug, such as CVE-2026-101356.

The October 2026 Tomcat releases fix eight CVEs across three supported branches. Three are rated Important by the Tomcat team, and five are Low. Two of the Important ones are response mix-ups between users, and one is a login check that fails open.

Not every CVE hits every branch. The AJP mix-up affects only the 11.0.x branch. A Unix socket bug affects only 9.0.x. The table lists each CVE with the affected ranges copied from the Tomcat security pages as of 26 October 2026. An M in a version, as in 11.0.0-M25, means a milestone: an early test release that came before 11.0.0.

The fixed versions are the same for every row: 11.0.27, 10.1.61 and 9.0.123. So one upgrade per branch clears all of them. Find your branch's column, then look closely at rows for features you use.

Older branches are not in the table but are not safe. The oss-security posts list Tomcat 8.5.0 to 8.5.100 and 7.0.0 to 7.0.109 as affected by the JNDIRealm and JSTL c:redirect bugs. Those branches are end of life and get no fix.

The security pages head the section with 12 October, while each CVE entry says it was made public on 20 October. The releases shipped first so users could upgrade before the details were public.

Find the exact Tomcat version your app runs, then compare it with the table above. A standalone install and a Spring Boot app each need a different check, shown below. If you only have a built jar or a container image, the jar script near the end reads the version for you.

Check a standalone Tomcat install

Run the version script in Tomcat's bin folder. On Linux and macOS that is version.sh, and on Windows it is version.bat. It runs Tomcat's ServerInfo class and prints a Server version line.

cd /opt/tomcat/bin
./version.sh | grep -E 'Server (version|number)'

On a patched 11.0.x server, expect "Server version: Apache Tomcat/11.0.27" and "Server number: 11.0.27.0". The number has a fourth part, which is the patch field from Tomcat's build and is 0 for these releases. Adjust the path to your install.

Check a Spring Boot app

The quickest check is the startup log. Embedded Tomcat logs a line that starts "Starting Servlet engine:" with the version in square brackets. On a fixed 4.x app it reads "Starting Servlet engine: [Apache Tomcat/11.0.27]".

To check the build without starting the app, ask your build tool which tomcat-embed-core version it resolves. Look for the line that names org.apache.tomcat.embed:tomcat-embed-core and read the version after it.

# Maven
mvn dependency:tree -Dincludes=org.apache.tomcat.embed

# Gradle
./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath

Pause and predict. Say the order-tracking API runs Spring Boot 4.0.8 with HTTP/2 on, DeferredResult endpoints, no AJP connector and no LDAP login, like the rest of the made-up setup. Which of the three Important bugs can reach it?

Spring Boot 4.0.8 manages Tomcat 11.0.24, which sits inside 11.0.22 to 11.0.26, so the HTTP/2 mix-up applies. It is inside the AJP range too, but the app has no AJP connector. It uses no JNDIRealm, so the login bug does not apply.

What just happened? You matched three things: the Tomcat version your build resolves, the range in the table, and whether your app uses the feature. A row is your problem only when all three line up. Upgrade anyway, because the Low fixes apply too.

Move to a Spring Boot release that manages a fixed Tomcat, or pin the Tomcat version yourself. Spring Boot picks the Tomcat version through a property called tomcat.version in its spring-boot-dependencies list.

Spring's 3.5.16 release post calls it the last open-source release of 3.5.x. So no free 3.5.x release will pick up 10.1.61. On 3.5.x, override the Tomcat version yourself and plan the move to 4.0.x or 4.1.x.

1. 1

   Find your current versions

   Note your Spring Boot version and the Tomcat version it resolves, using the commands from the version check section.

2. 2

   Pick the target

   On 4.0.x or 4.1.x, move to 4.0.9 or 4.1.2. On an older line, keep Spring Boot and pin Tomcat to the fixed version of the same branch.

3. 3

   Pin Tomcat if needed

   In Maven with the Spring Boot parent, set the tomcat.version property. In Gradle with the dependency management plugin, set ext['tomcat.version'].

4. 4

   Run your tests

   Spring Boot's docs warn that overriding a managed version can cause compatibility issues, so run the full test suite and a smoke test.

5. 5

   Rebuild every image

   Rebuild and redeploy every service and container image that bundles the old jar. A fixed pom.xml does not change images already running.

6. 6

   Confirm in production

   Check the startup log line for Apache Tomcat/11.0.27, 10.1.61 or 9.0.123 on each running instance.

For a standalone Tomcat, download the fixed release from tomcat.apache.org and back up the old install. Carry over your changes in conf, any extra jars in lib such as JDBC drivers, and bin/setenv.sh if you use one. Then restart and check with version.sh.

Pin Tomcat yourself on Spring Boot 3.5.x

On 4.0.x or 4.1.x, moving to 4.0.9 or 4.1.2 is enough, so you can skip to the next box. This part is for 3.5.x apps, whether they use the parent or import the Spring Boot BOM.

<properties>
    <tomcat.version>10.1.61</tomcat.version>
</properties>

That Maven snippet is for an app on Spring Boot 3.5.x that inherits spring-boot-starter-parent. If you import spring-boot-dependencies instead of using the parent, the property does nothing. Spring's docs say to add your own dependencyManagement entries before the import, here one entry for each org.apache.tomcat.embed or org.apache.tomcat artifact you use.

In Gradle with the dependency management plugin, the Groovy form is ext['tomcat.version'] = '10.1.61', and the Kotlin form is extra["tomcat.version"] = "10.1.61". If you import the BOM with Gradle's platform instead, properties do not work. Spring's docs show a resolution strategy, adapted here for Tomcat.

configurations.all {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        if (details.requested.group == 'org.apache.tomcat.embed') {
            details.useVersion '10.1.61'
        }
    }
}

We did not run these build snippets, because our test machine could not reach Maven Central. Run your build and the version check afterwards to confirm the result.

It happens when a server returns an object to its reuse pool while old code still holds it. The next request picks up the same object. If the old code then writes to it, that data goes to the new request's user.

Tomcat describes CVE-2026-101356 as incorrect object recycling and reuse in HTTP/2 processing of async servlets. It can cause request or response mix-up between users. The trigger is an error during async processing, so normal successful requests are not the path.

Here is an everyday picture. A busy canteen reuses numbered trays. A tray goes back to the shelf after each order, and the next order gets it. If a tray is sent back while a cook is still adding food, the next customer's tray gets the old customer's food.

Map it back to Tomcat. The tray is a request or response object. The cook is your async app code. The shelf is Tomcat's recycling. Where the picture breaks: in Tomcat the trigger is an error during async work, not a slow cook. The advisory does not publish the exact sequence, so the picture shows the shape, not the steps.

The 11.0.x fix commit, 1dc6aa15, is one line in AsyncStateMachine.java. The method isAsyncError now returns true for the state MUST_ERROR as well as ERROR. Its changelog note says the gap "could lead to unexpected IllegalStateExceptions for some error conditions."

The same changelog adds another line: "Harden HTTP/2 against applications that do not correctly handle asynchronous errors." The security page does not tie that line to this CVE. Our reading: app code that ignores async errors makes this class of bug easier to reach.

The AJP bug sent part of one response body after the response was treated as finished. That leftover data then arrived as the start of the next request's response on the same connection. Only 11.0.0-M25 to 11.0.26 are affected.

Tomcat's advisory calls it a buffer under-read and does not explain the term further. It says a large non-blocking write could split the response body between the current request and the next request on that connection. The second request would most likely fail, and data from the first response could leak into it.

Why does this cross users? A front server such as Apache httpd keeps AJP connections open and sends many requests through each one. Tomcat's AJP docs describe a keep-alive timeout for waiting on another request. So the next request on a connection can easily belong to a different user.

The fix commit, f13748ba, changes when Tomcat closes the response. Before, it closed as soon as the bytes written reached the declared Content-Length. The new code comment says that for non-blocking writes, bytes may still sit in Tomcat's socket buffer, so it waits.

The 11.0.27 changelog also says Tomcat now makes sure the non-blocking write buffer is empty before sending the AJP end-of-response message. Together these lines describe the shape: the response was marked done while part of the body had not left yet.

Our reading of the fix commit narrows it further. The changed check only differs for non-blocking writes, and Tomcat treats a write as non-blocking when the app registered a WriteListener. The changed check also applies only when the response declares a Content-Length, though the related changelog line about the AJP end message does not depend on that.

Ordinary Spring MVC controllers do not register a WriteListener. Spring WebFlux running on Tomcat does, in its ServletServerHttpResponse class. Treat this as a way to rank services, not a reason to skip the upgrade.

One fact limits who is exposed. AJP is off unless a connector names the AJP protocol, because Tomcat creates an HTTP connector when no protocol is given. In Spring Boot that means your own connector code.

The AJP connector's safety defaults do not help here. It listens only on the same machine and needs a shared secret, which stops strangers connecting directly. This mix-up happens on traffic your own front server forwards.

It failed open because Tomcat checked the password with the wrong login method. Fail open means a check that cannot do its job lets people in instead of keeping them out. With some login methods, the directory could accept the user without checking the typed password.

Some background first. A realm is Tomcat's list of users and roles. JNDIRealm reads them from an LDAP directory, the kind of company user store many offices use. SASL is a family of pluggable login methods, and GSSAPI is the Kerberos one.

Tomcat's realm docs describe two ways to check a password. If you set userPassword, Tomcat reads the stored password and compares it. If you do not, Tomcat binds to the directory as that user with the typed password, and a successful bind means the login worked.

The docs say that bind is a simple bind, which means a plain name and password. The old code reset the login method only when the realm named GSSAPI. Any other value in the realm's authentication attribute stayed in place for the password check. The fix commit, e43453fc, now always sets simple authentication there.

The advisory rates it Important. Your app is exposed if JNDIRealm checks passwords by binding, with no userPassword attribute, and its authentication attribute is set to anything other than simple or GSSAPI.

The advisory names non-GSSAPI SASL mechanisms. Our reading of the fix, which now forces a simple bind for every value, is that "none" was affected too. We checked Java's built-in LDAP client on JDK 21: with "none", it sends an anonymous bind that drops the typed name and password. So a directory that allows anonymous binds could then accept any password.

Remember the older branches from the CVE section. Tomcat 8.5.x and 7.0.x are hit by this bug too, and they get no fix, so the only way out is a supported branch.

Read the five Low fixes against your own setup. Each matters only when you use the feature it touches. The descriptions below come from the Tomcat security pages as of 26 October 2026.

• CVE-2026-88041, HTTP/2 trailers: trailers are headers sent after the body. Trailer data from a previous request could leak into a later one. The 11.0.x fix adds a lock around HTTP/2 header handling.
• CVE-2026-93446, TLS 1.3: incomplete cleanup could make TLS 1.3 connections fail now and then. The fix commit says a flag that tracks handshake progress was not reset.
• CVE-2026-74049, JSTL c:redirect in JSP pages: Tomcat's built-in version of this tag did not stop the page after the redirect. The rest of the page still ran.
• CVE-2026-74048, FIPS mode: FIPS is a US government standard for approved crypto. The advisory title on all three branch pages says OpenSSL-FFM. With the OpenSSL lifecycle listener, if FIPS failed to start, Tomcat logged an error and kept running in non-FIPS mode.
• CVE-2026-80353, 9.0.x only: a race when setting permissions on a Unix Domain Socket with the APR connector let an unauthorised local user reach the socket. The 9.0.x page calls it an incomplete fix for CVE-2026-65183.

If none of these features is in your setup, the Low fixes are a reason to upgrade on schedule, not in a panic. The Important ones decide how fast you move.

The advisories give one fix: upgrade. They list no workaround. You can still shrink your exposure until the upgrade lands, because each Important bug needs a specific feature to be in use.

• HTTP/2 mix-up: the bug is in HTTP/2 processing of async servlets. If you do not need HTTP/2 on Tomcat, turning it off removes that path. In Spring Boot, check whether server.http2.enabled is set to true. In server.xml, look for an UpgradeProtocol element naming Http2Protocol inside a Connector.
• AJP mix-up: look for a Connector with an AJP protocol in server.xml, or custom connector code in Spring Boot. If nothing uses it, remove it.
• JNDIRealm: look at the Realm element. If you find no userPassword attribute plus an authentication value other than simple or GSSAPI, such as "none" or a SASL mechanism, that realm is exposed, so upgrade it first.

These steps are our reading of the advisories, not official workarounds from the Tomcat team. Treat them as a short stopgap, not a replacement for the upgrade.

Read the small properties file Tomcat keeps inside tomcat-embed-core. This helps when you only have the built file, such as a Spring Boot fat jar in a container image. The Python script below uses only the standard library.

import io
import sys
import zipfile

PROPS = "org/apache/catalina/util/ServerInfo.properties"


def read_props(jar):
    names = jar.namelist()
    if PROPS in names:
        return jar.read(PROPS).decode("utf-8")
    # Spring Boot fat jar or executable war: Tomcat sits in a nested jar
    folders = ("BOOT-INF/lib/", "WEB-INF/lib-provided/", "WEB-INF/lib/")
    for name in names:
        if name.startswith(tuple(f + "tomcat-embed-core-" for f in folders)) and name.endswith(".jar"):
            with zipfile.ZipFile(io.BytesIO(jar.read(name))) as inner:
                return inner.read(PROPS).decode("utf-8")
    raise SystemExit("No Tomcat version file found in this file")


with zipfile.ZipFile(sys.argv[1]) as jar:
    text = read_props(jar)

for line in text.splitlines():
    if line.startswith(("server.info=", "server.number=")):
        print(line)

Save it as tomcat_jar_version.py and pass tomcat-embed-core-11.0.27.jar, your app's fat jar or an executable WAR. For a fat jar or WAR, it opens the nested tomcat-embed-core jar under BOOT-INF/lib, WEB-INF/lib-provided or WEB-INF/lib. Expect two lines: server.info=Apache Tomcat/11.0.27 and server.number=11.0.27.0.

They show that reuse is a trade: it saves memory and garbage collection, but every reused object must be fully reset and must not be shared with old work. Three of the eight CVEs are reuse or cleanup bugs: the HTTP/2 mix-up, the HTTP/2 trailer leak and the TLS 1.3 flag.

Tomcat exposes this trade in its settings. The processorCache attribute controls how many request processors it keeps for reuse, and the default is 200. The docs say 0 means no processor reuse, giving extra safety at a performance cost.

The discardFacades attribute defaults to true. That means the thin facade objects your servlet sees are thrown away after each request, while Tomcat's internal objects behind them are still reused. The docs describe facades as what isolates the container's internal request objects.

The same lesson applies to your own code. If you pool buffers, connections or objects, reset every field, and never let a callback keep a reference after you return the object. Async code makes this harder, because the old work can finish after you thought it was done.

Use the mix-up bugs as a story about shared state between users. Interviewers want to hear that you can find the shared part, name how it leaks and say how you would detect it.

1. 1

   Name the risk

   Say that a server reusing objects or connections across users can send one user's data to another, and that the October 2026 Tomcat fixes are real examples.

2. 2

   Point to the shared part

   For HTTP/2, it was recycled request and response objects after an async error. For AJP, it was one connection reused by many users' requests.

3. 3

   Explain the fix pattern

   Recycle only after all work on an object has finished, and mark a response done only when its bytes have actually left the buffer.

4. 4

   Add defence in depth

   Log a request ID with every response, compare it at the edge, and alert on mismatches. Keep dependencies patched on a fixed schedule.

5. 5

   Cover the rollout

   Inventory every service's Tomcat version, upgrade by risk, rebuild images and confirm the running version from the startup log.