Tomcat’s Login and HTTP/2 Fixes Need Different Checks
Tomcat’s October corrections address two different security decisions: whether one user can receive material belonging to another request, and whether a particular directory-backed login accepts an incorrect password. An inventory that records only “Tomcat patched” loses the configuration and version details needed to assess those paths. Match the running branch and the application’s actual authentication route before declaring the work complete.
Apache’s security pages place the corrected-build headings on 12 October and say the individual findings were made public on 20 October. The listed correction releases are 10.1.61, 11.0.27 and 9.0.123. Those dates describe different stages of the disclosure. They are not a new November patch announcement, and an available release does not establish what any particular server is running.
The HTTP/2 range starts later
CVE-2026-101356 concerns incorrect recycling and reuse of objects during HTTP/2 processing of asynchronous servlets. An error in that processing can result in requests or responses being mixed between users. That makes the request-handling path relevant to confidentiality and isolation between sessions. It is not evidence that every response is exposed or that an identified installation has suffered a leak.
The Apache-authored record gives three affected ranges: 11.0.22–11.0.26, 10.1.55–10.1.60 and 9.0.118–9.0.122. The corresponding listed corrections are 11.0.27, 10.1.61 and 9.0.123. A result for a different version or protocol path should not be substituted for that applicability check. Apache rates this issue Important.
The directory-login condition changes the scope
CVE-2026-101296 has a different prerequisite. It applies when JNDIRealm uses a SASL authentication mechanism other than GSSAPI. A missing validation step can allow authentication without the correct password. The configured realm and mechanism are therefore central to the assessment. The finding does not say that every login implemented by an application running on Tomcat can be bypassed.
Its current-branch affected ranges extend back to 11.0.0-M1, 10.1.0-M1 and 9.0.0.M1, ending at 11.0.26, 10.1.60 and 9.0.122 respectively. These lower bounds differ substantially from the HTTP/2 finding, although the listed correction releases are the same. Apache also rates this issue Important. Keep the issue-specific range alongside the configured authentication path in the maintenance record.
The original authentication record additionally identifies 8.5.0–8.5.100 and 7.0.0–7.0.109 as known affected versions that were already at end of life when the record was created. It warns that other unsupported versions may also be affected. Their absence from the three current correction routes is not an assurance of safety. Moving an older application to a supported branch needs compatibility planning with its owner, rather than an assumption that changing the version number completes a migration.
Verify the deployment, not just the download
Start with an accurate map of the service: the running Tomcat instance, package supplier, application, exposed connectors and authentication configuration. Check the build actually loaded by the service, rather than a file downloaded to a maintenance workstation. Where a distributor or appliance supplier packages Tomcat, use that supplier’s notice for its exact product and package. An upstream version floor alone does not prove that a differently numbered package is vulnerable or corrected.
Plan the authorised update and recovery with the deployment owner. Preserve the configuration and application dependencies needed to return the service to a known state. After maintenance, verify the resulting build and legitimate application behaviour, including directory-backed sign-in and the HTTP/2 routes used in that environment. Record which instances were checked. These are operational verification steps, not a claim that a test has been performed or that a particular system was compromised.
This review focuses on the two Important findings above. The same branch notices contain further corrections, including an AJP response issue on 11 and a Unix-domain-socket permission race on 9, alongside other TLS, trailer-handling, Jasper and FIPS-related entries. Their applicability differs. Review the complete notice for the deployed branch instead of treating two issue checks as a complete release assessment.
The useful outcome is a traceable decision: an applicable finding, the relevant configuration, a supported correction route and evidence from the running service. Keep possible prior exposure separate from confirming the update. A clean version check can establish the installed build; it cannot, by itself, settle whether earlier cross-user disclosure or unauthorised authentication occurred.
