Tomcat Vulnerability ResponseEight Flaws, AWS, Spring Boot, and Legacy Deployments【October 2026】

1. The decision: update, then verify authentication and the path into Tomcat

Information checked: October 23, 2026, Japan Standard Time. Apache disclosed eight Tomcat vulnerabilities on October 20; Japan's JVN published its notice on October 21. The upstream releases containing the fixes are 9.0.123, 10.1.61, and 11.0.27. Apache's release headings are dated October 12, while the individual disclosures say October 20. These dates describe different events. ^[1][2][3][4]

Start with two boundaries: password validation in a particular LDAP authentication configuration, and separation of users' requests and responses in HTTP/2 and AJP processing. Knowing that a machine contains Tomcat is the beginning of the investigation. Its running version, enabled features, and reachable paths determine the next steps.

A distribution or product vendor may backport a fix while retaining an older upstream version number. Match the CVE, the full package version, and the vendor advisory before declaring such a package vulnerable or fixed. The existence of an upstream release also does not prove that a downstream repository already supplies it. ^[14]

The operational recommendation here is to identify the boundary at risk, restrict paths reaching it when necessary, and retain evidence that the patched implementation runs across every deployment unit. Authentication, separation between users, local permissions, and cryptographic operating modes are different boundaries. One configuration change will not address all eight issues.

2. What was disclosed: read the eight issues by feature

Tomcat runs Java web applications. It is a different product from Apache HTTP Server and may be deployed as a standalone installation or embedded as a library in a Spring Boot application. An asset inventory containing only application names can therefore miss the runtime underneath. ^[8][10]

Eight is the number of distinct vulnerabilities across the branches. Apache rates three Important and five Low. Each branch does not have all eight: the AJP issue, CVE-2026-103119, appears in this month's Tomcat 11 list, while the APR issue, CVE-2026-80353, appears in the Tomcat 9 list. ^[1][2][3][4]

Use this table to direct the investigation, then consult the affected range for each CVE. The HTTP/2 mix-up affects comparatively recent releases, whereas the JNDIRealm issue spans much broader ranges. A scanner marking one CVE inapplicable does not resolve the other findings on that server.

When severity scores differ, keep the assessor and scoring version attached

Apache's Important rating is not the same scale as a CVSS number. Amazon Linux assigns CVSS v3 scores of 7.4 to the authentication issue and 4.8 to the HTTP/2 mix-up. Red Hat explains that product configuration and distribution differences can change vendor assessments. Compare the assessor, CVSS version, and assumptions before interpreting a difference in numbers. ^[12][13][14]

The Apache and JVN notices reviewed here do not establish exploitation of all eight vulnerabilities in the wild. This article therefore does not present widespread exploitation as confirmed. The absence of incident details in those notices is also not evidence that a particular deployment is unaffected. Use verified exposure conditions and the sensitivity of the data to make remediation decisions.

3. Authentication bypass: the effective JNDIRealm mechanism matters

CVE-2026-101296 concerns JNDIRealm configured with a SASL authentication mechanism other than GSSAPI. Authentication may succeed without the correct password. Apache lists 9.0.0.M1–9.0.122, 10.1.0-M1–10.1.60, and 11.0.0-M1–11.0.26 as affected supported-branch ranges. ^[2][3][4]

A Realm connects user identities, credentials, and roles to Tomcat's authentication facilities. JNDIRealm consults a directory service. Its effective authentication mechanism depends on configuration and the provider: the authentication attribute selects a mechanism, and omitting it uses the provider's default. An empty setting is consequently not enough to rule the issue out. ^[7]

An analogy is a reception desk issuing an access badge after finding a name on a list but before completing identity verification. That illustrates the missing boundary; it does not mean that every Tomcat authentication implementation has the same defect.

Finding a name and verifying an identity are separate steps. Establish the actual Realm and mechanism in the deployment.

A useful investigation order is:

1. Identify who performs authentication. Include application-managed logins and external identity-provider integration when drawing the path.
2. Locate JNDIRealm use. Inspect Engine, Host, and Context configuration, inheritance, and nested Realms inside CombinedRealm or LockOutRealm.
3. Resolve the effective mechanism. Cross-check the authentication value, directory-side configuration, and settings injected at startup.
4. Determine reachability and authority. Include administrative interfaces, alternate ports, accessible data, and granted roles.

If an application performs its own authentication and you can establish that JNDIRealm is unused, this CVE's configuration condition does not apply to that path. Other issues, including HTTP/2 processing, still require their own assessment.

Changing the authentication mechanism as a temporary measure requires validation of user lookup, LDAP transport protection, and role assignment. Merely inserting the word GSSAPI does not configure a working authentication system. An untested switch can interrupt logins or weaken protection elsewhere. If the replacement cannot be validated promptly, restricting access to the affected feature can provide a clearer boundary while arranging the update.

4. HTTP/2 and AJP: authenticated users still need isolated responses

CVE-2026-101356 concerns object recycling and reuse during HTTP/2 processing of asynchronous Servlets. Error handling can lead to requests or responses crossing between users. The affected ranges are 9.0.118–9.0.122, 10.1.55–10.1.60, and 11.0.22–11.0.26. ^[5]

Think of reusable delivery trays. A delivery is interrupted, and a tray is returned to service before its previous contents or destination have been fully cleared. Even when each recipient has authenticated correctly, the delivery boundary can fail. Application authorization tests alone are poorly suited to establishing that this lower-level separation remains intact.

The boundary depends on clearing the previous state, including after errors, before reuse.

Distinguish HTTP/2 at the browser-facing edge from HTTP/2 received by Tomcat. A load balancer may accept HTTP/2 and forward HTTP/1.1. Along that path, Tomcat's HTTP/2 processing is not used. AWS Application Load Balancers send HTTP/1.1 to targets by default; target-group protocol settings can instead select HTTP/2 or gRPC. ^[11]

Follow the whole route: target-group settings, the reverse proxy's upstream protocol, the Tomcat Connector, and any directly reachable ports. A temporary HTTP/2 restriction must remove the affected path into Tomcat. Changing only the external edge may leave another internal route active, and protocol changes need validation for workloads such as gRPC.

Internal AJP connections can carry responses for many users

CVE-2026-103119 affects AJP in 11.0.0-M25–11.0.26. A buffer under-read during a large non-blocking write can split a response body between the current and following request. Apache describes failure of the second request as the most likely result, with possible leakage of data from the first response into the second. ^[6]

An AJP listener need not be publicly exposed for user separation to matter. A front-end web server may relay requests for many users over the internal connection. Identify the users and data crossing AJP instead of ending the assessment at “internal network.” Disable unused Connectors and prioritize patched software where the path is required.

CVE-2026-88041 also involves residual state: HTTP/2 trailer information may remain for a subsequent request. Examine how the application uses that trailing metadata. TLS connection failures and continued JSTL processing have different conditions, so disabling HTTP/2 cannot be counted as resolving all eight findings. ^[3]

5. Find every copy: standalone Tomcat, Spring Boot, and containers

The following is an operational proposal for applying the public information. Paths and artifact names are examples; identify the intended environment before running them. Configuration and logs may contain credentials, so retain only the necessary fields in shared records.

For standalone Tomcat, identify the installation used by the service and inspect that installation's version:

/path/to/running-tomcat/bin/version.sh

This reports the software in that directory. The running process may have started elsewhere, so reconcile the service definition, startup logs, CATALINA_HOME, and CATALINA_BASE. A patched file on disk does not establish that the old Java process has stopped.

For Spring Boot, inspect embedded dependencies. Servlet-based applications can bundle Tomcat without it appearing in the operating system's Tomcat package inventory. Other configurations, including those using a different server with WebFlux, exist. The Spring Boot name alone does not establish whether Tomcat is present. ^[10]

# Dependencies in a Maven project
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed

# Runtime dependencies in a Gradle project
./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath

# Also inspect the Spring Boot JAR that will actually be deployed
jar tf application.jar | rg 'BOOT-INF/lib/tomcat-embed-'

If dependency resolution and the delivered artifact disagree, investigate the build target, caches, dependency management, and the artifact that reached deployment. Prefer an update compatible with the Spring Boot branch and its managed dependencies. Avoid ad hoc replacement of a single Tomcat JAR. If an emergency version override is necessary, align related Tomcat modules and run the application's regression checks.

For containers, record the build input and running deployment separately. Updating a base image does not remove an old Tomcat bundled inside the application JAR. Rebuilding that JAR also does not remove old tasks or Pods still serving traffic.

• Record the image tag, immutable digest, and embedded Tomcat version.
• Verify replacement across all replicas and stop new traffic reaching old units.
• Update the definitions used by autoscaling and disaster recovery.
• If a rollback target is vulnerable, define the restrictions and re-patching steps that must follow recovery.

An inventory row is more useful when it identifies a service, environment, executable artifact, entry point, and owner than when it records only a server. Testing environments and administrative tools deserve higher priority if they reach production identities or real data.

6. AWS and legacy versions: distinguish delivery, ownership, and backports

At the October 23 check, Amazon Linux's CVE pages listed the following states for the two principal issues. This is not a remediation-completion table for every CVE in every product. ^[12][13]

Pending Fix does not mean fixed. A successful package-update command cannot install a security fix that has not reached the configured repository. These states change quickly; consult the CVE page's Advisory field and the fixed package version when performing the work.

For example, package metadata can be inspected as follows. Match the output against an advisory rather than treating the presence or absence of output as a verdict:

rpm -qa | rg '^tomcat'
dnf updateinfo info --cves CVE-2026-101296,CVE-2026-101356

The dnf example applies to environments supporting it and is not a replacement for an AL2-specific procedure. Manually installed and application-embedded Tomcat will not appear in an RPM inventory. Connect the operating-system and application inventories.

An upstream fix, a distributable package, and a running replacement are separate delivery stages.

Ownership depends on deployment. A self-installed runtime on EC2, an application image used by ECS or EKS, and software maintained by a product vendor have different update owners. “Hosted on AWS” does not define what updates automatically. Ask which artifact must be rebuilt and redeployed, and who owns that action.

Changing distribution also changes the next update

Moving to an upstream distribution while waiting for a vendor fix is an option, but it can move maintenance outside the existing package-management process. Startup behavior, ownership, log locations, and update responsibility may change. Record installation, recovery, and ongoing ownership rather than treating an emergency file copy as the finished process. A private source backport is an option only when someone can validate and maintain it.

A major branch migration adds Java and application compatibility work. Current upstream requirements are Java 8 or later for Tomcat 9, Java 11 or later for 10.1, and Java 17 or later for 11. Moving from 9 to 10 or later also involves the Java EE to Jakarta EE transition. Separate the urgent security patch from the longer migration plan. ^[8][9]

Ask a product vendor for the product release, bundled Tomcat version, applicability of each CVE, fixed deliverable, application procedure, and restart requirement. For an end-of-life branch, omission from a current advisory is not proof of safety. A version that was not investigated is different from one verified unaffected.

7. When an immediate update is unavailable: define containment and continued-operation criteria

The following is the article's operational guidance, not an Apache guarantee of a universal workaround. Tie every temporary restriction to a CVE and path, with an expiry and an owner for reassessment.

Prioritize restricting or stopping access when affected authentication protects important data or administrative actions reachable externally and no prompt fix is possible. Do the same when an affected HTTP/2 or AJP path shows signs suggesting data crossover. Consider entry-point restrictions, disabling the affected feature, or removing an execution unit from service, while preserving relevant evidence.

Consider time-limited operation with the affected path removed when, for example, traffic into Tomcat has been changed from HTTP/2 to HTTP/1.1, direct access paths are closed, and the other CVEs have been assessed separately. Validate performance, asynchronous behavior, and workloads such as gRPC before changing protocols. The evidence should establish which vulnerable path was removed, rather than merely documenting a disabled setting.

Keep an unresolved status visible when a packaged product hides its effective configuration or runtime version, or when no evidence of a claimed backport is available. Apply restrictions based on exposure and data sensitivity, and set a deadline for obtaining the missing answer. Do not convert uncertainty into “not affected.”

A WAF may provide additional protection, but it does not repair internal object reuse or LDAP authentication code. If deploying a rule for a specific CVE, inspect the provider's stated coverage and limitations. Enabling a generic attack rule is not evidence that responses cannot cross between users.

An application's maintenance page may be generated only after the request has already reached Tomcat. If containment is intended to prevent that reachability, verify enforcement in front of the runtime. Include management ports, internal routes, and alternative hostnames when checking for entries outside the restriction.

8. Completion: make the patched version and the running version agree

Do not close the change record on a successful command exit alone. Four forms of evidence make completion understandable to the next operator:

1. Evidence of the fix: the upstream fixed release, or a vendor advisory naming the CVE and full fixed package version.
2. Evidence of execution: startup logs, artifact identifiers, image digests, and replacement results for all execution units.
3. Evidence of function: regression checks for valid and invalid passwords, differently privileged test identities, asynchronous responses, and the protocols actually used.
4. Evidence against reintroduction: definitions for new instances, recovery targets, maintenance ownership, and conditions for lifting temporary restrictions.

Use dedicated accounts and synthetic data. Obtaining another person's real information is not an appropriate verification method. A small test that fails to reproduce crossover does not prove the absence of a timing-dependent bug. Center the decision on evidence that the fixed implementation is running, using functional testing to detect operational regressions.

Verify coverage across the fleet, including the definitions that will start the next instance.

For incident review, correlate authentication events with application actions, user reports, asynchronous-processing errors, and unusual responses. A successful access-log entry does not establish that the delivered body was correct. When evidence is suspicious, involve the security owner in scoping and preservation rather than inferring “no disclosure” from ordinary operational logs.

What carries over from PHP2Shell response

The PHP2Shell guide shares three foundations with this response: inventory the runtime beneath the application, verify the distribution's fix, and verify execution after deployment. Tomcat adds a strong emphasis on effective authentication and protocol configuration. Vulnerabilities disclosed in the same week do not automatically justify the same workaround or shutdown decision.

The immediate task is to fill in five fields for each service: running Tomcat, effective Realm, protocols reaching Tomcat, fixed deliverable, and post-restart evidence. Record why an issue is inapplicable, assign owners and deadlines where it applies, and preserve uncertainty where facts are missing. That record also reduces repeated investigation when the next advisory arrives.

This is an explanation based on public primary sources, not a report of reproduction testing or incident investigation in an individual environment. Distribution status changes; check current advisories and product-vendor instructions when applying a fix.