Apache Tomcat CVE-2026-101296: JNDIRealm Bypass and 7 More Fixes

On 20 October 2026 Apache Tomcat disclosed eight vulnerabilities. The most serious, CVE-2026-101296, lets a login succeed without the correct password when JNDIRealm uses a non-GSSAPI SASL mechanism. Upgrade to 11.0.27, 10.1.61 or 9.0.123. Tomcat 8.5 and 7.0 are end of life and will not be fixed. No exploitation is reported.

This is a vulnerability disclosure, not a breach. Nobody has reported attacks using these flaws, none of them is in the CISA Known Exploited Vulnerabilities (KEV) catalog as of the 23 October catalog release, and we found no public proof of concept. It is still a batch worth acting on this week. Two of the three issues Apache rates Important can hand one user's data to another user, and the third lets someone log in without knowing the password on an uncommon but real configuration.

The reason this post sits in our supply chain category is simple. Most Tomcat in the world is not a Tomcat you installed. It arrives inside Spring Boot applications as tomcat-embed-core, inside vendor products, inside container base images and inside appliances. Finding all of it is the hard part of this patch cycle, so we spend a good share of this post on that.

What happened

Apache's Tomcat security team published eight CVEs through three channels on 20 October 2026: the Tomcat announce mailing list, the oss-security list and the per-branch security pages at tomcat.apache.org. The fixed releases themselves carry a 12 October date on those security pages, so patched builds were available about a week before the details went public. That is normal Tomcat practice: ship the release, then publish the advisories once users have had a chance to upgrade.

Apache rated three issues Important and five Low. All eight are fixed in the same three releases:

• Apache Tomcat 11.0.27
• Apache Tomcat 10.1.61
• Apache Tomcat 9.0.123

Not every CVE affects every branch. CVE-2026-103119 (an AJP response mix-up) exists only in Tomcat 11. CVE-2026-80353 (a Unix domain socket permission race) exists only in Tomcat 9. The JNDIRealm bypass and the JSTL redirect issue go back to the first milestone of every supported branch and also affect the end of life 8.5 and 7.0 lines.

The three Important issues

CVE-2026-101296: JNDIRealm bind credential validation fails open for non-GSSAPI SASL mechanisms. Apache's description says that when JNDIRealm was configured with a SASL authentication mechanism other than GSSAPI, attackers could authenticate "without providing the correct password." The CVE record classifies it as CWE-304, Missing Critical Step in Authentication. External researchers reported it to the Tomcat security team on 14 September 2026.

CVE-2026-101356: HTTP/2 request/response mix-up after an error during async processing. Apache describes incorrect recycling and reuse of objects in HTTP/2 handling of asynchronous servlets, which can cause a "request and/or response mix-up between users." It affects only recent releases: 11.0.22 onward, 10.1.55 onward and 9.0.118 onward. It was reported on 16 September 2026.

CVE-2026-103119: AJP response mix-up. A buffer under-read (CWE-127) meant a large non-blocking write over AJP could split a response body between the current request and the next request on the same connection. Apache says the most likely result is failure of the second request, with "possibly leakage of data from the first response to the second." Only Tomcat 11.0.0-M25 to 11.0.26 is affected. It was reported on 16 September 2026.

The five Low issues

• CVE-2026-93446: possible TLS 1.3 connection failures. Incomplete cleanup could make TLS 1.3 connections fail intermittently. The 11.0.27 changelog describes the fix as resetting a flag Tomcat uses to track TLS handshake progress.
• CVE-2026-88041: HTTP/2 trailer header cross-contamination. Trailer information from one request could leak into a later request.
• CVE-2026-74049: Jasper JSTL <c:redirect> plug-in omits page abort. Tomcat's built-in replacement for the JSTL redirect tag did not stop page processing, so the rest of the JSP ran after the redirect was issued. This is the classic Execution After Redirect pattern.
• CVE-2026-74048: OpenSSL-FFM FIPS failure does not prevent start-up. If OpenSSLLifecycleListener is configured for FIPS mode and FIPS activation fails, Tomcat logs an error and carries on with JSSE in non-FIPS mode.
• CVE-2026-80353 (Tomcat 9 only): TOCTOU when setting Unix domain socket permissions on the APR/Native connector. This one completes an earlier fix. CVE-2026-65183, fixed in 9.0.121 in August, addressed the same race for the NIO connector only. The new CVE covers the APR/Native connector.

A note on that last ID, because it caused confusion in early write-ups. The 9.x security page lists both numbers: CVE-2026-65183 under the 9.0.121 entry from August, and CVE-2026-80353 under 9.0.123 with the title "Fix for CVE-2026-65183 did not address APR connector." They are two separate CVEs. If you track the October batch, the ID you want is CVE-2026-80353.

Timeline

All times are UTC. Times to the minute come from the mailing list archives and CVE record metadata.

The gap between the 12 October release date and the 20 October disclosure matters for anyone who reads release notes rather than advisories. The 11.0.27 changelog already described the JNDI fix, saying "a simple bind is always used" when checking a user's own name and password, before the CVE existed publicly. Teams that upgrade on release rather than on advisory were protected a week earlier.

Who is affected

The short answer is anyone running a Tomcat older than 11.0.27, 10.1.61 or 9.0.123. The useful answer depends on configuration, because the three Important issues each need a specific feature switched on.

We want to be clear about the JNDIRealm case. A non-GSSAPI SASL configuration is unusual, and we do not know how many deployments use it. If you do not configure JNDIRealm at all, CVE-2026-101296 does not apply to you. If you use it with simple bind or GSSAPI, Apache's description does not cover your setup. The upgrade is still the right move, but the emergency is for the minority with SASL.

Where Tomcat hides

The installed server is the easy case. These are the places teams tend to miss:

• Spring Boot fat jars and WAR files. Spring Boot's web starter pulls in org.apache.tomcat.embed:tomcat-embed-core and related artifacts. The Tomcat version is set by the Spring Boot dependency management unless you override it.
• Other embedding frameworks and tools. Anything that depends on tomcat-embed-core, tomcat-catalina, tomcat-coyote or tomcat-jasper carries the affected code.
• Container images. Official tomcat images, internal base images, and application images that copy a Tomcat distribution into /usr/local/tomcat or /opt/tomcat.
• Operating system packages. Linux distributions ship their own tomcat9 or tomcat10 packages and backport fixes on their own schedule.
• Vendor software and appliances. Many commercial products bundle a Tomcat for their web console or API. You cannot patch those yourself; the vendor has to ship an update.
• End of life installs. Tomcat 8.5 reached end of life in March 2024 and 7.0 in March 2021, according to Apache's end of life notices. Both are affected by CVE-2026-101296 and CVE-2026-74049 and will not receive fixes.

How the issues work

This section explains the mechanisms in plain language so you can judge your exposure. It does not include attack steps.

CVE-2026-101296 in plain terms

JNDIRealm connects Tomcat to an LDAP directory. Tomcat's documentation describes two ways it can check a password. It can retrieve a password attribute from the user's directory entry and compare it locally. Or, if no userPassword attribute is configured, it binds to the directory as the user, using the user's DN and the password they typed, and treats a successful bind as proof of identity. The documentation says that bind is a simple bind.

The authentication attribute on the Realm element sets the mechanism Tomcat uses for its directory connection. The documentation lists the values none, simple, strong or a provider specific mechanism. For GSSAPI the code already made sure the user's password check did not use GSSAPI. The fix commit for 11.0.x (e43453fc, titled "Always use a simple bind to validate a user and password via a bind") shows what was missing: before the fix, Tomcat only stepped away from the configured mechanism when that mechanism was GSSAPI. With any other SASL mechanism configured, the bind meant to prove the user's password ran under that mechanism instead of a simple bind. Apache's advisory states the result: attackers could authenticate without the correct password.

The fix is small. During the user's credential check Tomcat now always sets the bind to simple, then restores whatever mechanism was configured before. The changelog entry says this brings the code in line with the documentation.

One practical point follows from how JNDIRealm maps users to roles: a login that succeeds without the right password carries whatever application roles the directory gives that user. That is why administrative and service accounts deserve the closest look when you review logs. Apache's advisory does not describe an attack, and neither will we.

CVE-2026-101356 in plain terms

Tomcat reuses request and response objects between requests to save memory and allocation time. That reuse is safe only if every object is fully reset before its next use. The advisory says that after an error during asynchronous processing on an HTTP/2 connection, the recycling went wrong, so a request or response could be mixed up between users. In the worst case one user receives a response meant for someone else, which might include personal data or a session cookie. The 11.0.27 changelog also lists a change that hardens HTTP/2 against applications that mishandle asynchronous errors, which fits the same area.

Because the bug needs an error during async processing, it is not something every request triggers. CISA's ADP assessment marks it as automatable, which means an attacker would not need a human in the loop to attempt it, but also marks exploitation as none.

CVE-2026-103119 in plain terms

AJP is a binary protocol that a front end web server uses to forward requests to Tomcat over a long lived connection. Apache says a large non-blocking write could leave part of the response body in a buffer that was not fully drained before the next response on that connection began. The likely symptom is a broken second request. The worse case is that bytes from the first user's response appear in the second user's response. The changelog lists two related fixes: making sure the non-blocking write buffer is empty before sending an AJP end response message, and a fix for large non-blocking writes stalling on AJP connections.

This is not an AJP exposure problem like Ghostcat (CVE-2020-1938). It happens on legitimate proxy traffic. Binding AJP to localhost and setting a secret reduces who can talk to the connector, but it does not stop this bug.

The Low issues in one paragraph each

HTTP/2 trailers (CVE-2026-88041). Trailers are headers sent after the body. Incomplete cleanup let trailer values from one request appear in a later one. Applications that read trailers for integrity or routing decisions are the ones to think about.

TLS 1.3 failures (CVE-2026-93446). A handshake tracking flag was not reset, so some TLS 1.3 connections failed. This is an availability and reliability issue, not data exposure.

JSTL redirect (CVE-2026-74049). Code after <c:redirect> kept running. If a JSP relies on the redirect to stop processing, for example after an authorization check, the rest of the page executes anyway, and its side effects happen even though the browser follows the redirect.

FIPS fail-open (CVE-2026-74048). If you require FIPS and the OpenSSL FIPS provider fails to activate, Tomcat used to log and continue with non-FIPS JSSE. After the fix, the changelog says Tomcat now throws an error when FIPS is requested but not available, which aligns OpenSSLLifecycleListener with AprLifecycleListener. Expect a start-up failure after upgrading if your FIPS setup was quietly broken.

Unix domain socket race (CVE-2026-80353). On Tomcat 9 with the APR/Native connector, a window between creating the socket file and setting its permissions let a local user connect. This needs local access.

Technical details

Everything in this section is taken from the Apache Tomcat security pages, the announce and oss-security posts, the CVE records and the NVD API, all fetched on 24 October 2026.

Affected and fixed versions per CVE

For the two CVEs that reach back to 8.5 and 7.0, the CVE records add that "other unsupported versions may also be affected." In practice that means you should treat Tomcat 8.0, 10.0 and other unsupported lines as affected unless shown otherwise.

Fix commits per branch

The security pages link each fix to a commit in the apache/tomcat repository. Use these to confirm a backport in a distribution package or a vendor build.

The 11.0.x JNDIRealm commit touches two files: java/org/apache/catalina/realm/JNDIRealm.java (4 lines added, 5 removed, in bindAsUser) and webapps/docs/changelog.xml.

Scores and weakness classes

Apache publishes a severity label, not a CVSS score. CISA's Authorized Data Publisher (ADP) container in the CVE records adds scores and an SSVC assessment. The two sources disagree on how alarming these are, and you should see both.

Read the 101296 vector carefully. AT:P means "attack requirements present": the vulnerable configuration must exist. A base score cannot express that most deployments lack the configuration. Apache's Important label reflects that context; the 9.1 reflects what happens if you have it. At the time of writing NVD shows CVE-2026-101296 as "Awaiting Analysis" with no NVD primary score. We did not find ADP scores for the five Low issues in the records we fetched.

Security NEXT reported on 23 October that a security organisation rated some of the issues critical without naming which. The CISA ADP scores above are the likely source, but the article does not say so, and we have not confirmed it.

Advisory identifiers and message references

Thread IDs resolve at https://lists.apache.org/thread.html/ followed by the ID. The announce message for CVE-2026-101296 has Message-ID 91e0dd46-db26-486a-9809-3d75600b9480@apache.org and lists the mitigation as upgrading to one of the three fixed releases. It names no workaround.

Maven coordinates and images

We did not confirm a Spring Boot 3.x release that moves to Tomcat 10.1.61. If you run Spring Boot 3.x, override the Tomcat version yourself until one ships (steps below).

Supported Java versions per branch, from Apache's "which version" page: Tomcat 11.0.x needs Java 17 or later, 10.1.x needs Java 11 or later, and 9.0.x needs Java 8 or later. That matters if you are on 8.5 and planning a jump: 9.0.123 is the smallest supported step from 8.5 because it keeps the javax.* namespace, while 10.1 and 11 move to jakarta.*.

Indicators of compromise

There are none. Apache published no indicators, no exploitation has been reported, and CISA's SSVC entries all say "Exploitation: none." Anyone selling you an IOC list for this batch is guessing. What you can do is look for the behaviour each bug would cause, which we cover in the detection steps below.

What to do now

Work through these steps in order. The first two answer "are we exposed", the rest fix it.

1. Find every Tomcat, including embedded ones

For a server install, check the version directly:

# Standard distribution
$CATALINA_HOME/bin/version.sh

# If version.sh is missing, read the version from catalina.jar
unzip -p $CATALINA_HOME/lib/catalina.jar org/apache/catalina/util/ServerInfo.properties

For a running container:

docker exec <container> /usr/local/tomcat/bin/version.sh
# or inspect an image without running the app
docker run --rm --entrypoint /usr/local/tomcat/bin/version.sh <image>

For Maven projects:

mvn -q dependency:tree -Dincludes=org.apache.tomcat.embed:tomcat-embed-core
mvn -q dependency:tree -Dincludes=org.apache.tomcat

For Gradle projects:

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

For built artifacts where you have no source:

# Spring Boot fat jar
unzip -l app.jar | grep -E 'tomcat-embed-core-[0-9]'

# WAR or exploded directories
find / -name 'tomcat-embed-core-*.jar' -o -name 'catalina.jar' 2>/dev/null

For distribution packages:

# Debian and Ubuntu
dpkg -l | grep -E 'tomcat(9|10|11)'
# RHEL, Fedora and derivatives
rpm -qa | grep -i tomcat

Distribution packages backport fixes without changing the upstream version number, so compare against your distribution's security tracker and the commit IDs above, not only the version string.

If you keep SBOMs, search them for the package URL prefix pkg:maven/org.apache.tomcat.embed/tomcat-embed-core and pkg:maven/org.apache.tomcat/. Our post on finding affected products fast with SBOMs walks through that search across a portfolio.

2. Check configuration for the three Important issues

JNDIRealm with SASL (CVE-2026-101296). Search the server and per-application configuration:

grep -rn --include='*.xml' 'JNDIRealm' \
  $CATALINA_BASE/conf \
  $CATALINA_BASE/webapps/*/META-INF/context.xml \
  $CATALINA_BASE/conf/Catalina 2>/dev/null

For each hit, look at the authentication attribute on that Realm element. If it is absent, "none", "simple" or "GSSAPI", Apache's description does not cover it. If it names another SASL mechanism, such as DIGEST-MD5, treat the instance as exposed. Also note whether userPassword is set: the advisory title refers to bind credential validation, which is the mode used when userPassword is not set. Apache does not say whether the compare mode is affected, so upgrade in either case.

Embedded Tomcat rarely uses JNDIRealm, because Spring Boot applications usually authenticate in the application layer. Search your code anyway:

grep -rn 'JNDIRealm' --include='*.java' --include='*.kt' --include='*.xml' .

HTTP/2 plus async servlets (CVE-2026-101356). Look for the HTTP/2 upgrade protocol on any connector:

grep -rn 'Http2Protocol' $CATALINA_BASE/conf/server.xml

In Spring Boot, HTTP/2 is controlled by server.http2.enabled=true. Then check for asynchronous processing: <async-supported>true</async-supported> in web.xml, asyncSupported = true on @WebServlet or @WebFilter, or Spring MVC controllers that return asynchronous types such as DeferredResult, Callable or CompletableFuture, which Spring MVC runs through servlet async processing. Remember the version floor: only 11.0.22, 10.1.55 and 9.0.118 and later are affected.

AJP on Tomcat 11 (CVE-2026-103119).

grep -rn 'AJP/1.3' $CATALINA_BASE/conf/server.xml

If you find an AJP connector on Tomcat 11.0.0-M25 to 11.0.26, you are in scope.

3. Check the Low issues that need configuration

# FIPS mode requested through OpenSSL (CVE-2026-74048)
grep -rn 'OpenSSLLifecycleListener' $CATALINA_BASE/conf/server.xml

# JSTL redirect in JSPs (CVE-2026-74049)
grep -rln 'c:redirect' $CATALINA_BASE/webapps --include='*.jsp' --include='*.jspx' --include='*.tag'

# Tomcat 9 APR connector on a Unix domain socket (CVE-2026-80353)
grep -rn 'unixDomainSocketPath' $CATALINA_BASE/conf/server.xml

If you require FIPS, read your start-up logs from the last restart for errors from OpenSSLLifecycleListener about FIPS. If one is there, you have been running without FIPS and need to fix the provider, not only Tomcat.

4. Upgrade

For a standalone install, download 11.0.27, 10.1.61 or 9.0.123 from tomcat.apache.org, verify the signature, and replace the binaries while keeping conf/, webapps/ and lib/ customisations. Verify the download:

gpg --import KEYS
gpg --verify apache-tomcat-11.0.27.tar.gz.asc apache-tomcat-11.0.27.tar.gz
sha512sum -c apache-tomcat-11.0.27.tar.gz.sha512

For Spring Boot 4.x, move to 4.1.2 or 4.0.9. For any Spring Boot version, or until your line ships a release, override the managed Tomcat version.

Maven, in the properties section of the project's pom.xml:

<properties>
  <tomcat.version>11.0.27</tomcat.version>
</properties>

Gradle with the Spring dependency management plugin, in build.gradle:

ext['tomcat.version'] = '11.0.27'

Use 10.1.61 instead for Spring Boot 3.x, which is built on Tomcat 10.1. Rebuild, then re-run the dependency tree from step 1 to confirm the resolved version changed.

For containers, update the base image tag and rebuild:

FROM tomcat:11.0.27-jdk21-temurin-noble

Pin by digest once you have pulled it, so a later rebuild cannot silently move.

For distribution packages, apply your vendor's update when it is published and check its changelog for the commit IDs above.

For vendor products that bundle Tomcat, ask the vendor which Tomcat version their current release includes and whether the October CVEs apply to their configuration. Most products do not use JNDIRealm with SASL, but they often enable HTTP/2 or AJP.

5. Interim mitigations if you cannot upgrade today

These come from how the features work, not from Apache, which lists upgrading as the only mitigation.

• CVE-2026-101296: switch the authentication attribute away from the non-GSSAPI SASL mechanism. Simple bind over LDAPS (an ldaps:// connection URL, or StartTLS) keeps passwords off the wire, and GSSAPI is outside the described flaw. Test logins before and after the change.
• CVE-2026-101356: remove the Http2Protocol upgrade from connectors, or set server.http2.enabled=false in Spring Boot. Clients fall back to HTTP/1.1. If a proxy in front of Tomcat terminates HTTP/2 and speaks HTTP/1.1 to Tomcat, Tomcat's HTTP/2 code is not in the path.
• CVE-2026-103119: switch the proxy to Tomcat link from AJP to HTTP if you can. If not, upgrade Tomcat 11 first among your fleet.
• CVE-2026-74049: review JSPs where code after <c:redirect> has side effects, and add an explicit return after the redirect where it matters.
• 8.5 and 7.0: there is no mitigation that makes an end of life Tomcat supported. If you cannot move, apply the configuration changes above, restrict who can reach the instance, and set a migration date.

6. Verify

After upgrading, confirm the version from the running process, not just the file on disk. version.sh against the live CATALINA_HOME, or the Server version printed at start-up in catalina.out, both work. For embedded applications, add the Tomcat version to a health or info endpoint if you have not already, so the next audit is a query rather than a hunt.

Then test the paths you changed. Log in through JNDIRealm with a correct and an incorrect password and confirm the incorrect one fails. Exercise an async endpoint over HTTP/2 under load. If you require FIPS, confirm Tomcat starts and logs FIPS mode as active.

How to look for signs of the bugs in your logs

There are no IOCs, but each Important bug leaves traces you can look for.

• JNDIRealm: compare successful logins in your access logs or application audit trail against the directory server's own logs. A successful Tomcat login with no corresponding successful password check on the directory side, for a user who did not log in, is the pattern to investigate. Pay attention to administrative and service accounts since 12 October and earlier.
• HTTP/2 async mix-up: support tickets in which a user saw someone else's data, unexplained session switches, or responses that do not match the request path in your access logs. Errors logged during async processing on HTTP/2 connections are the trigger condition Apache describes.
• AJP mix-up: intermittent failures of the second request on an AJP connection after a large response, and proxy errors about malformed AJP responses.

These signals are weak and noisy. Absence of evidence here does not prove you were not affected, and presence of a weird ticket does not prove you were. They are a reason to look further, not a verdict.

What changed since first reports

• The severity picture moved. On 20 October only Apache's labels existed. By 21 October CISA's ADP container had added 9.1 scores to all three Important issues. Some coverage now calls them critical. Apache still rates them Important, and we think the configuration requirements justify that.
• The 9.x ID was clarified. Early notes cited CVE-2026-65183 for the Tomcat 9 socket race. The oss-security post and the 9.x page make clear the October issue is CVE-2026-80353, a follow-up to the August CVE.
• Downstream started shipping. Spring Boot 4.1.2 and 4.0.9 picked up Tomcat 11.0.27 on 22 October. Official container image tags for all three fixed releases were available by 24 October.
• Still nothing on exploitation. No public proof of concept, no exploitation report, and no KEV listing as of catalog 2026.10.23.

Open questions

• How many deployments use non-GSSAPI SASL with JNDIRealm? Nobody has published data. We expect few, but the users who do are likely enterprises with central LDAP, where an admin login matters.
• Is the compare mode (userPassword set) affected? Apache's title and fix point at the bind path. We have not seen a statement either way about the compare path.
• Will Spring Boot 3.x ship a release with Tomcat 10.1.61? We did not find one at the time of writing.
• Which Linux distributions have backported the fixes? Check your distribution's tracker; we did not survey them.
• Will NVD add its own scores? NVD lists CVE-2026-101296 as Awaiting Analysis.

Tomcat's history in KEV, for context

None of the October CVEs is in KEV. Tomcat is not a stranger to the catalog, though, and that history is a reason to keep your patch path short. The 23 October catalog lists six Tomcat entries:

The pattern worth noticing is that several of these were added long after disclosure. Tomcat bugs tend to be exploited on the long tail of unpatched and forgotten instances, which is exactly where the end of life 8.5 and 7.0 installs sit.

What would have helped

There was no breach to prevent. The useful question is what makes this kind of batch a routine afternoon instead of a two week hunt.

Practices any team can use

• An inventory that sees embedded Tomcat. A list of servers is not enough. You need to know which applications carry tomcat-embed-core and at which version, which images contain a Tomcat distribution, and which vendor products bundle one. SBOMs produced at build time, kept per release, answer that in minutes.
• Configuration inventory for risky features. Record which instances use JNDIRealm and with which authentication value, which connectors enable HTTP/2 and which use AJP. The three Important bugs each depend on a feature switch; knowing your switches turns "are we affected" into a lookup.
• Upgrade on release, not on advisory. Tomcat shipped the fixes on 12 October and disclosed on 20 October. A routine that picks up Tomcat point releases within days gets ahead of disclosure every time.
• One place to set the Tomcat version. For Spring Boot, a single tomcat.version property in a shared parent POM or Gradle convention plugin lets you move every service at once.
• A plan for end of life lines. If 8.5 or 7.0 still runs anywhere, you now have two published CVEs that will never be fixed there. Put a date on the migration.
• Fail closed on compliance controls. The FIPS fail-open bug is a good reminder to test that a required control actually stops start-up when it is missing, rather than trusting a log line.
• A short, boring rebuild path. Base image bumped, dependency override merged, tests run, deployed. If that takes days instead of hours, the bottleneck is the thing to fix.

Zero-Day Discovery and Gold

Two Safeguard capabilities relate to the habit this post argues for. We want to be exact about what they are and are not.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. External researchers reported them to Apache, and Apache fixed them.

Gold Open Source at gold.safeguard.sh is free and needs no login. It provides searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh, a paid service, provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

We have not confirmed that Gold holds records or hardened builds for these October Tomcat CVEs, so we do not claim it. The habit these capabilities support is the one this batch rewards: look up the safe version quickly, pull patched and signed components from a curated source, and rebuild fast.

Where Safeguard fits

Safeguard is a software supply chain security platform. For this batch, the honest fit is inventory, matching, prioritising and rebuilding:

• Finding Tomcat. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> scans an SBOM, with results written as JSON under ./output. The platform shows which projects contain a given component and version, so "where do we ship tomcat-embed-core below 11.0.27" is a query, not a meeting.
• Matching against vulnerability databases. Safeguard matches components against vulnerability data, so the October CVEs show up against the projects that carry affected versions.
• Reachability analysis. It helps rank findings by whether your code paths reach the vulnerable code, which is useful when you have dozens of services to move and need an order.
• Policies and gates. Policies evaluated in the platform can block a build that resolves a Tomcat version you have decided not to ship.
• Autonomous remediation. When a fixed version exists, fix pull requests can bump the dependency or the tomcat.version property. It ships off by default.
• The Safeguard CLI assistant. It can edit a pom.xml, build.gradle or Dockerfile and run your build and tests, asking before each command under the permission mode you choose (/permissions: Ask, Accept edits, Plan, Auto, Strict). safeguard exec runs the same work in CI.

Where Safeguard does not help: it does not read your server.xml and tell you whether JNDIRealm uses SASL or whether HTTP/2 is on. That configuration check is yours, and the grep commands above cover it. It cannot patch the Tomcat inside a vendor appliance or a hosted service, and it cannot make an end of life 8.5 or 7.0 install supported. A distribution package that backports fixes without a version change needs your distribution's tracker. And no tool prevents a vulnerability that has not been disclosed yet; what tools can shorten is the time from disclosure to a rebuilt, deployed service.

When you are ready to try it, download Safeguard and read the CLI documentation.

For a broader view of this month, see our roundup of October 2026 security incidents and what would have helped. If you build Java services into containers, container image supply chain incidents in 2026 covers the image side of the same problem, and the incident response playbook for a compromised dependency is a useful template for running a patch cycle like this one, even though nothing here was compromised.

Common mistakes and troubleshooting

Patching the server and forgetting the jars. Upgrading the standalone Tomcat on a VM does nothing for the Spring Boot services that bundle their own tomcat-embed-core. Run step 1 against your build artifacts, not only your hosts.

Trusting the version string on a distribution package. Debian, Ubuntu and Red Hat backport fixes. A 9.0.x package with a lower upstream number may already contain the fix, and a package with a higher number may not if it was built before 12 October. Check the changelog.

Setting tomcat.version in the wrong place. In Maven, the property must be in the project that imports the Spring Boot parent or BOM, and some setups import the BOM in a way that ignores the property. Run mvn dependency:tree after the change and confirm the version moved.

Mixing Tomcat major lines. Overriding a Spring Boot 3.x application to Tomcat 11.0.27 will not work: Spring Boot 3.x is built for Tomcat 10.1. Use 10.1.61 there.

FIPS start-up failure after the upgrade. If Tomcat now refuses to start with an error about FIPS, the upgrade worked. Your FIPS provider was not activating before, and Tomcat used to hide that. Fix the OpenSSL FIPS configuration rather than removing the FIPS setting.

Disabling HTTP/2 at the wrong layer. If a load balancer speaks HTTP/2 to clients and HTTP/1.1 to Tomcat, disabling HTTP/2 on the balancer changes nothing for this bug and costs you performance. The setting that matters is on the Tomcat connector.

Assuming AJP hardening covers CVE-2026-103119. secret and a localhost bind are good practice, and they limit who can reach the connector. They do not stop the response mix-up on legitimate proxy traffic.

Leaving 8.5 because "it is internal." CVE-2026-101296 is an authentication bypass. Internal admin consoles are exactly where JNDIRealm against a corporate directory tends to live.

Changing authentication without testing. Moving from DIGEST-MD5 to simple bind without LDAPS sends passwords in clear text to the directory. Use ldaps:// or StartTLS when you make the switch.

FAQ

What is CVE-2026-101296?

An authentication bypass in Apache Tomcat's JNDIRealm. When JNDIRealm is configured with a SASL mechanism other than GSSAPI, Apache says attackers could authenticate without providing the correct password. It affects Tomcat 11.0.0-M1 to 11.0.26, 10.1.0-M1 to 10.1.60 and 9.0.0.M1 to 9.0.122, plus the end of life 8.5 and 7.0 lines.

Which Tomcat versions fix the October 2026 vulnerabilities?

Tomcat 11.0.27, 10.1.61 and 9.0.123. All eight CVEs are fixed in those releases, for the branches each one affects. Apache dates the releases 12 October 2026 on its security pages.

Is anyone exploiting these Tomcat bugs?

No exploitation has been reported. None of the eight CVEs is in the CISA KEV catalog as of version 2026.10.23, CISA's SSVC entries for the three Important issues record exploitation as none, and we found no public proof of concept.

Why do some sources call these critical when Apache says Important?

CISA's ADP container in the CVE records assigns base scores of 9.1 to all three Important issues. Base scores assume the vulnerable configuration is present. Apache's label weighs how specific those configurations are. Both are valid views; your own configuration decides which is closer to your risk.

Are Tomcat 8.5 and 7.0 going to get fixes?

No. Both are end of life, and the CVE records list them as affected with no fixed version. Move to 9.0.123 if you need to stay on the javax.* namespace, or to 10.1.61 or 11.0.27 if you can migrate to jakarta.*.

Does Spring Boot need an update?

If your application uses embedded Tomcat, yes. Spring Boot 4.1.2 and 4.0.9 ship Tomcat 11.0.27. For Spring Boot 3.x, override tomcat.version to 10.1.61 until a release picks it up. Whether the Important bugs matter to you still depends on HTTP/2, async use and, rarely in Spring Boot, JNDIRealm.

I use JNDIRealm with simple bind. Am I affected by CVE-2026-101296?

Apache's description covers non-GSSAPI SASL mechanisms only. Simple bind and GSSAPI are outside it, as is the default when authentication is not set and your provider defaults to simple. Upgrade anyway, but this is not an emergency for you.

How do I mitigate the HTTP/2 mix-up before I can upgrade?

Remove the Http2Protocol upgrade protocol from the affected connectors, or set server.http2.enabled=false in Spring Boot. Clients fall back to HTTP/1.1. Only Tomcat 11.0.22, 10.1.55, 9.0.118 and later releases before the fix are affected.

What is the AJP bug, and does it affect Tomcat 9?

CVE-2026-103119 can split a large non-blocking AJP response across two requests, which may leak part of one user's response to another. Only Tomcat 11.0.0-M25 to 11.0.26 is affected. Tomcat 10.1 and 9.0 are not.

Who found these issues?

Apache credits external researchers for each CVE except CVE-2026-101356, whose oss-security post lists no finder. The JNDIRealm issue was reported on 14 September 2026 and the two response mix-ups on 16 September 2026.

Fix it without waiting for upstream

For this Tomcat batch the fix already exists upstream, so the gap that matters is the one between 11.0.27 shipping and that version running in every service and image you build. The same steps apply to the next disclosure that arrives before a release does.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Tomcat. Each shows a real flow that maps onto the work this batch asks of Java teams.

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For this batch you would ask the same assistant to set tomcat.version to 11.0.27 in your pom.xml, or bump the FROM tomcat tag in your Dockerfile, then run mvn verify and approve each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is the step that answers "which of our services ship tomcat-embed-core below 11.0.27" across the repositories and images you already have checked out.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. The same flow fits a Spring Boot service: point it at the repository, let it propose the move to Spring Boot 4.1.2 or a tomcat.version override, and approve the build and test commands one at a time.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Apache Tomcat 11.x vulnerabilities (tomcat.apache.org)
• Apache Tomcat 10.x vulnerabilities (tomcat.apache.org)
• Apache Tomcat 9.x vulnerabilities (tomcat.apache.org)
• Tomcat announce list: CVE-2026-101296 advisory (lists.apache.org)
• Tomcat announce list: CVE-2026-101356 advisory (lists.apache.org)
• Tomcat announce list: CVE-2026-103119 advisory (lists.apache.org)
• oss-security: CVE-2026-74048 OpenSSL-FFM FIPS failure (openwall.com)
• oss-security: CVE-2026-74049 Jasper JSTL redirect (openwall.com)
• oss-security: CVE-2026-80353 Unix domain socket TOCTOU (openwall.com)
• oss-security: CVE-2026-88041 HTTP/2 trailer cross-contamination (openwall.com)
• oss-security: CVE-2026-93446 TLS 1.3 connection failures (openwall.com)
• oss-security: CVE-2026-101296 JNDIRealm (openwall.com)
• oss-security: CVE-2026-101356 HTTP/2 async mix-up (openwall.com)
• oss-security: CVE-2026-103119 AJP response mix-up (openwall.com)
• CVE-2026-101296 record (cve.org)
• CVE-2026-101356 record (cve.org)
• CVE-2026-103119 record (cve.org)
• CVE-2026-101296 in the NVD API (nvd.nist.gov)
• CISA Known Exploited Vulnerabilities catalog feed (cisa.gov)
• Fix commit e43453fc: always use a simple bind to validate a user and password (github.com/apache/tomcat)
• Apache Tomcat 11.0.27 changelog (tomcat.apache.org)
• The Realm component configuration reference (tomcat.apache.org)
• Which version of Tomcat do I want? (tomcat.apache.org)
• Tomcat 8.5 end of life notice (tomcat.apache.org)
• Tomcat 7.0 end of life notice (tomcat.apache.org)
• tomcat-embed-core Maven metadata (repo1.maven.org)
• Spring Boot 4.1.2 release notes (github.com)
• Spring Boot 4.0.9 release notes (github.com)
• Official tomcat image tags (hub.docker.com)
• Security NEXT: eight vulnerabilities in Apache Tomcat, 23 Oct 2026 (Japanese)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.