Apache Tomcat October 2026 security update: patch and verify

Apache Tomcat disclosed a security batch on October 20, 2026 that includes three Important issues across supported branches: an authentication fail-open in JNDIRealm, an HTTP/2 request/response mix-up, and—on Tomcat 11—an AJP response mix-up. Production teams should upgrade to Tomcat 9.0.123, 10.1.61, or 11.0.27, replace every running instance, and verify the version and configuration that actually serve traffic. A reverse proxy or WAF does not repair these flaws inside Tomcat.

This guide separates vendor facts from engineering analysis. Affected ranges, fixed releases, severity labels, and vulnerability mechanics come from the Apache Tomcat security pages, verified on October 25, 2026. The rollout and detection steps are defensive recommendations. Apache's advisories do not claim active exploitation, so this article does not describe vulnerable exposure as a confirmed breach.

The decision in one table

Tomcat 10.0 is end-of-life. Apache says vulnerabilities reported after October 31, 2022 are not checked against that branch and will not be fixed there. Move 10.0 deployments to a supported 10.1 or 11 line rather than treating an old 10.0 build as unaffected.

CVE-2026-101296: JNDIRealm authentication can fail open

The highest identity risk is CVE-2026-101296. When JNDIRealm uses a non-GSSAPI SASL authentication mechanism, a missing validation step can allow authentication without the correct password. Apache rates the issue Important.

The affected ranges are broad:

• Tomcat 9.0.0.M1 through 9.0.122;
• Tomcat 10.1.0-M1 through 10.1.60;
• Tomcat 11.0.0-M1 through 11.0.26.

The vulnerability is configuration-dependent. A Tomcat server that does not use JNDIRealm with a non-GSSAPI SASL mechanism is not exposed through that specific path. Do not infer safety from a package version alone, but do not infer compromise from it either.

Inventory the effective Realm configuration, not just templates in source control. Search each deployed server.xml and included configuration source for JNDIRealm, saslMechanism, directory URLs, alternate Realms, inherited Helm values, and environment-specific overrides. Protect any diagnostic output because directory endpoints and bind identities can be sensitive.

If the condition exists, prioritize the service as an authentication-boundary update. After patching, run positive and negative authentication tests in staging and a canary: a valid credential should pass, an invalid password must fail, a disabled user must fail, and authorization must still reject a valid user without the required role. Do not test by attacking production accounts.

CVE-2026-101356: HTTP/2 users can receive mixed request or response data

CVE-2026-101356 concerns incorrect recycling and reuse of internal objects after an error during asynchronous servlet processing. Apache says it can trigger request and/or response mix-up between users.

Affected ranges are narrower:

• Tomcat 9.0.118 through 9.0.122;
• Tomcat 10.1.55 through 10.1.60;
• Tomcat 11.0.22 through 11.0.26.

Exposure requires the relevant HTTP/2 and asynchronous processing path. Teams should identify whether HTTP/2 terminates at Tomcat or at an upstream proxy, and whether applications use async servlets, Servlet 3 asynchronous APIs, reactive bridges, long polling, or other components that dispatch asynchronously. Proxy termination can reduce direct reachability, but it is not evidence that every internal connection and error path avoids the flaw.

Patch first. Then canary realistic HTTP/2 traffic with concurrent users and deliberately induced safe application errors. Check that correlation IDs, authenticated principals, response bodies, cache keys, and tracing spans remain bound to the originating request. This is a correctness and privacy test, not a substitute for the fixed release.

CVE-2026-103119: Tomcat 11 AJP response mix-up

CVE-2026-103119 applies to Tomcat 11.0.0-M25 through 11.0.26. A buffer under-read during a large non-blocking write can split a response body between the current AJP request and the next request on the same connection. Apache says the likely result is failure of the second request, with possible leakage from the first response into the second.

The issue matters only where AJP is enabled and receives traffic. Inventory connectors with protocol="AJP/1.3" or equivalent configuration, the proxy modules that use them, connection reuse, bind addresses, and the AJP secretRequired policy. Disable an unused AJP connector; if AJP is required, upgrade and keep it bound to a trusted network segment with a configured secret. Network restrictions reduce reachability but do not correct the buffer bug.

Do not generate large malicious payloads against production. Validate the patch in a controlled environment using normal large asynchronous responses, concurrent requests, unique response markers, and strict assertions that no marker crosses request boundaries.

The October release also carries Low-severity fixes

The same fixed releases include branch-specific Low issues such as intermittent TLS 1.3 failures, HTTP/2 trailer cross-contamination, a JSTL redirect processing problem, and startup continuing outside requested FIPS mode when OpenSSL-FFM FIPS activation fails. Tomcat 9 also fixes an APR Unix-domain-socket permission race.

These issues may be operationally important in regulated or multi-tenant environments even when the vendor rating is Low. Consume the complete fixed release rather than attempting to cherry-pick only the three Important fixes. Apache does not publish binary patches; normal remediation is a supported release or a documented vendor package that backports the relevant commits.

Inventory the version that is really running

Start with the process and artifact, not a package manifest on a build workstation:

$CATALINA_HOME/bin/version.sh
java -cp "$CATALINA_HOME/lib/catalina.jar"   org.apache.catalina.util.ServerInfo

In containers, run the check against the exact immutable image digest deployed by the orchestrator. A mutable tag can point to a newer build while old Pods still execute the vulnerable digest. Also inspect bundled or embedded Tomcat dependencies in executable JARs; version.sh on the host does not identify a private embedded container inside an application artifact.

Create an inventory row for service, owner, environment, Tomcat branch, full version, artifact digest, Java version, Realm type, SASL mechanism, HTTP/2 termination point, async-servlet use, AJP status, and rollout state. Unknown configuration should be investigated, not silently classified as not affected.

Safe upgrade workflow

1. Select the fixed branch. Choose 9.0.123, 10.1.61, or 11.0.27. Treat a distribution backport as fixed only when its vendor advisory maps the package build to the relevant CVEs.
2. Rebuild immutably. Update the base image or server package, rebuild the application, and record the new digest. Remove copied lib JARs that could shadow the fixed server libraries.
3. Diff configuration. Compare connectors, Realms, valves, TLS, AJP, HTTP/2, session settings, and JVM flags. Do not overwrite production secrets with package defaults.
4. Run compatibility tests. Cover login failures, role mapping, async error handling, HTTP/2 concurrency, proxy headers, sessions, uploads, WebSockets, and graceful shutdown.
5. Canary. Send a small traffic share to the fixed image, monitor authentication failures, 5xx responses, HTTP/2 resets, AJP errors, latency, and session behavior.
6. Replace the fleet. Roll all replicas, jobs, standby nodes, and autoscaling templates. Drain old connections where response mix-up is a concern.
7. Verify. Read the version and image digest from every serving instance. Confirm no old replica can return through a load balancer, scheduled job, rollback target, or disaster-recovery pool.

Kubernetes and container verification

For an image-pinned workload, verify both the declared image and the running image ID:

kubectl -n prod get deploy,sts -o wide
kubectl -n prod get pods   -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image,ID:.status.containerStatuses[*].imageID'

Then execute the version check through an approved administrative path in representative Pods. Avoid publishing a version endpoint to the internet merely for this rollout. If the application embeds Tomcat, query build metadata or the embedded server library rather than assuming the base image owns the runtime.

A completed Deployment rollout is insufficient if CronJobs, one-off Jobs, horizontal autoscaling templates, or a separate region still reference an older digest. Search the deployment source and the live cluster state.

Detection and incident review without overclaiming

The vendor advisories establish vulnerable conditions; they do not establish exploitation in your environment. Use three labels:

• Vulnerable exposure: an affected version and reachable configuration existed.
• Attempted exploitation: logs or telemetry show behavior crafted to exercise the vulnerable path.
• Confirmed compromise: independent evidence shows unauthorized authentication, cross-user disclosure, process control, or downstream impact.

For JNDIRealm, preserve authentication outcomes, directory bind results, user identifiers, source metadata, role-mapping decisions, and configuration history. Look for successful sessions paired with failed or absent credential validation, but account for service accounts, SSO, retries, clock skew, and log sampling before drawing conclusions.

For HTTP/2 or AJP mix-up, correlate request IDs, principals, connection IDs, stream IDs, trace IDs, response hashes, 5xx events, and user reports. A single mismatched log line can come from instrumentation bugs; corroborate it with application, proxy, network, and business evidence.

If evidence suggests unauthorized authentication or cross-user data exposure, preserve logs and volatile evidence according to policy, scope affected identities, revoke sessions, rotate reachable credentials, and involve incident response. Restarting the service may restore availability but does not prove containment.

Best practices and anti-patterns

Best practices

• Patch to a fixed supported branch and record the immutable artifact digest.
• Maintain a live inventory of Tomcat version, connector protocols, Realm configuration, and traffic termination.
• Keep AJP disabled unless needed; when used, bind it narrowly and require a secret.
• Test negative authentication and cross-request isolation during canaries.
• Keep request, principal, connection, stream, and trace identifiers available for investigation without logging secrets.
• Rehearse rollback, but ensure rollback artifacts are also fixed.

Anti-patterns

• Calling every vulnerable installation compromised.
• Treating a reverse proxy, WAF, or private subnet as a patch.
• Checking only Maven or OS package metadata while an embedded or copied Tomcat JAR serves traffic.
• Updating a mutable container tag without replacing all old Pods.
• Disabling HTTP/2 or AJP temporarily and forgetting the broad JNDIRealm issue.
• Publishing diagnostic endpoints that reveal exact versions or secrets.

Executive checklist

1. Find every standalone and embedded Tomcat deployment.
2. Upgrade to 9.0.123, 10.1.61, or 11.0.27.
3. Prioritize non-GSSAPI SASL JNDIRealm, HTTP/2 async servlet, and Tomcat 11 AJP deployments.
4. Rebuild immutable images and test authentication, async errors, HTTP/2, and AJP boundaries.
5. Replace every instance and verify the live version plus digest.
6. Preserve evidence and separate exposure, attempts, and confirmed compromise.
7. Remove vulnerable rollback images and autoscaling templates.

Related reading: Node.js October 2026 security patch guide, PHP2Shell patch and verification, Kubernetes TLS certificate rotation, and the engineering article library.

Primary references

• Apache Tomcat 9 security advisories
• Apache Tomcat 10 security advisories
• Apache Tomcat 11 security advisories
• Apache Tomcat security considerations
• Apache Tomcat AJP connector reference
• Apache Tomcat Realm configuration reference
• Unsplash License
• Taylor Vick — licensed data center photograph

Prepared by: Noor Yasser