Apache Tomcat CVE-2026-101356: CVSS 9.1 Data Mix-Up, Patch Now

A web server makes one promise above all others: your response comes back to you, and nobody else sees it. Two flaws the Apache Tomcat team disclosed on October 20 break exactly that promise. In the right conditions, Tomcat can hand one user's request, or one user's response, to a different user on the same connection, with no attacker involved. The United States National Vulnerability Database scores both at 9.1 out of 10; the Tomcat project rates each as important. Both are already fixed.

The fixed builds, Tomcat 11.0.27, 10.1.61 and 9.0.123, shipped on October 12. The vulnerability details went public eight days later, on October 20, when Tomcat committer Mark Thomas posted them to the oss-security mailing list. So if you patched in the normal October cycle you are already covered. If you did not, the clock on these started the day the details became searchable. There is no public exploit or proof-of-concept as of disclosure, and neither flaw needs one to bite: both can trigger on their own under ordinary load.

One connection, two users, crossed wires

CVE-2026-101356 lives in Tomcat's HTTP/2 handling of asynchronous servlets. When an error interrupts async processing, Tomcat recycles an internal object too eagerly, and the leftover state bleeds into the next exchange on that connection. The result Thomas describes is blunt: the exchange meant for one person lands in front of another.

CVE-2026-103119 is a different root cause with the same consequence. A buffer under-read in the AJP connector means that when the server writes a big response without blocking, the body can spill past its own request. The tail of user A's response gets stitched onto the front of whatever comes next on the connection. Usually the later request simply fails, but the advisory is explicit that bytes from the earlier response can surface in the later one. Tomcat credits Tuomo Hanninen with finding it.

Neither is a classic break-in. There is no payload to send and no endpoint to hit. These are failures of isolation: the server loses track of which bytes belong to which client. For a login page, that can mean a session cookie or an authenticated response going to the wrong browser. For an application that returns personal data, it can mean one customer seeing another customer's record. The damage depends entirely on what your responses carry.

The two bugs do not overlap cleanly. The HTTP/2 flaw reaches back across all three supported branches, as the table shows. The AJP flaw is narrower: only the 11.0 branch carries it. If you run 10.1 or 9.0, the AJP mix-up does not touch you, but the HTTP/2 one does.

Where the exposure is: asynchronous HTTP/2 and the AJP connector

Scope matters here more than the score. The HTTP/2 flaw only fires when three things line up: the HTTP/2 upgrade is enabled on your connector, the application uses asynchronous servlets, and an error interrupts that async work. Plenty of Tomcat deployments run HTTP/1.1 only and never touch async processing. If that is you, CVE-2026-101356 is not your problem, though the version is still worth moving.

The AJP connector is the one our audience should look at hardest. AJP, the Apache JServ Protocol, is the binary channel Tomcat speaks when it sits behind a front-end web server, Apache HTTP Server through mod_jk or mod_proxy_ajp, or nginx. If you terminate traffic at Apache or nginx and proxy to Tomcat over AJP, this is your connector. AJP has a history of being left too open, the 2020 Ghostcat flaw being the memorable example, so treat any AJP listener as a sensitive surface.

$CATALINA_HOME/bin/version.sh
Server number:  11.0.26.0
<Connector protocol="HTTP/1.1" port="8080">
    <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
</Connector>
<Connector protocol="AJP/1.3" address="127.0.0.1" port="8009" secretRequired="true" />

Run version.sh to read the exact build you are on and compare it against the table above. In conf/server.xml, the UpgradeProtocol line tells you whether HTTP/2 is active, and an AJP/1.3 connector tells you the AJP surface is live. Binding AJP to 127.0.0.1 and setting a secret shrinks its exposure, which is good practice regardless, but be clear with yourself: that hardening does not fix either mix-up. Only the upgraded build does.

Why logs will not tell you it happened

This is the part the patch notes skip. You cannot scan for a mix-up, and you will not find it waiting in an access log. A crossed response is not an error Tomcat records as its own fault; it is a 200 that went to the wrong place, or a request that failed for a reason the logs attribute to the client. The first signal is almost always human: a user reports seeing someone else's account, or an application throws an integrity error it cannot explain. By then the leak has already happened.

So the honest detection posture is indirect. Know which of your servers run an affected build, because the version is the one thing you can actually enumerate. This is where knowing which of your servers are exposed to a new CVE beats hunting for an exploit signature that does not exist. On the application side, watch for the tells of session confusion: responses whose session identifier does not match the client that should have received it, and spikes in requests failing mid-stream on reused connections. Those are weak signals, but for this class of bug they are the only ones you get before a customer finds it first.

Three crossed-wire bugs in one release

Here is the pattern worth more than either CVE on its own. The 11.0.27 release did not fix one isolation bug. It fixed three. Alongside the AJP and HTTP/2 async mix-ups, Tomcat also patched CVE-2026-88041, a lower-severity HTTP/2 trailer header cross-contamination where header data leaks between streams. All three are the same failure wearing different clothes: state that was supposed to belong to one request or connection leaking into the next. The common thread is Tomcat's machinery for reusing connections and recycling objects, the exact layer that makes a high-performance server fast, and the exact layer where a mistake turns into one user reading another's data.

We have watched this theme build. Request and response boundaries are quietly one of the most fragile parts of modern web infrastructure, from request smuggling in Apache Traffic Server to the connection-handling flaws we logged in Undertow. The same 11.0.27 release even carried a separate fail-open authentication bug in Tomcat's JNDIRealm, echoing the week we spent on controls that defaulted to allow instead of deny. Performance features and isolation guarantees pull in opposite directions, and object recycling is where that tension shows up as a security advisory.

Update your Tomcat build, then look for mismatched responses

The fix is unambiguous and already available. Move to 11.0.27 if you are on the 11.0 branch, 10.1.61 on 10.1, or 9.0.123 on 9.0. That single step closes both mix-ups and the trailer-contamination bug in one go, so there is no reason to stage them. If you manage Tomcat behind a reverse proxy, confirm the AJP connector is bound to loopback with a secret while you are in server.xml, and if nothing in front of you needs AJP, consider removing that connector entirely.

Then do the thing the advisory does not ask for: go back and check whether a mix-up already happened in the window before you patched. Pull any user reports of seeing the wrong account since mid-October, and review application logs for session identifiers that jumped between clients. A flaw that leaks data silently is only closed for new traffic the moment you upgrade; it says nothing about what crossed wires last week.