Apache Tomcat CVE Round-Up: 7 Vulnerabilities Disclosed June 2026, Including CVE-2026-55957

Apache Tomcat disclosed seven CVEs on June 29, 2026. Six of them are fixed in the new Tomcat 9.0.119 release: one rated Moderate (a default servlet security constraint bypass) and five rated Low. The seventh, CVE-2026-55957, is the serious one. It is rated Important, it is an authentication bypass in the JNDIRealm, and it was fixed in earlier releases (9.0.101, 10.1.37, and 11.0.5), with its public advisory landing on the same day as the rest.

If you are on a supported Tomcat 9.0.x build, the practical path is simple: upgrade to 9.0.119 and you close all seven, since the 9.0.101 fix for the auth bypass is already rolled into every later 9.0.x release.

The picture is different if you are on Tomcat 8.5, which reached end-of-life on March 31, 2024. Six of these seven CVEs apply to 8.5, including the Important JNDIRealm authentication bypass, and there is no 8.5 release that fixes any of them. The only one that does not affect 8.5 is the FFM connector issue (CVE-2026-53434), because that connector did not exist yet in the 8.5 line. So if you are running 8.5 in production, this disclosure is not a "patch and move on" event. It is six unpatched findings on a branch Apache no longer supports.

Here is the full breakdown, the affected version ranges, the 8.5 applicability, and what each group of teams should actually do.

A note on severity and sourcing: the severity ratings below are Apache's own, since the Tomcat security team acts as the CNA. At the time of writing, NVD had received all seven CVEs but had not yet published CVSS scores (vulnerability status: Received). The 8.5 applicability reflects HeroDevs analysis, since Apache no longer publishes advisories for the 8.5 branch; the 8.5 range for CVE-2026-55957 is also confirmed in the upstream Apache advisory. You can verify the supported-branch details and NVD scores at the linked CVE pages.

‍

The seven CVEs disclosed June 29, 2026

CVE-2026-55957 | Important | JNDIRealm authentication bypass via GSSAPI bind

The headline finding. The JNDIRealm is how Tomcat authenticates users against an LDAP or directory server. When it was configured to authenticate binds using GSSAPI (Kerberos), a missing step in the authentication flow let an attacker authenticate without supplying the correct password. That is a straight authentication bypass, which is why it is the only Important-rated issue in this group.

The scope is specific: it applies when JNDIRealm is configured for GSSAPI authenticated bind. It does not affect every Tomcat install. But where that configuration is in use, typically Active Directory or Kerberos-backed enterprise authentication, the impact is exactly what it sounds like, and that pattern is common in the large regulated environments where Tomcat tends to live.

This one was fixed earlier than the rest of the batch. The fix shipped in Tomcat 9.0.101, 10.1.37, and 11.0.5, and the public advisory was published on June 29, 2026. Per the Apache and NVD advisories, the affected ranges are 11.0.0-M1 to 11.0.4, 10.1.0-M1 to 10.1.36, 9.0.0.M1 to 9.0.100, and, on the end-of-life branches, 8.5.0 to 8.5.100 and 7.0.0 to 7.0.109. Older unsupported versions may also be affected. This is not Tomcat's first authentication-layer finding either: the Realm and authentication code has produced issues before, including a JNDIRealm escaping weakness (CVE-2021-30640) and a JASPIC authentication bypass (CVE-2024-52316).

CVE-2026-55956 | Moderate | Default servlet security constraint bypass

When a security constraint was configured for the default servlet, the HTTP method (or method omission) defined in that constraint was ignored. In plain terms: an access rule you wrote to apply to specific methods on static resources was not enforced the way you configured it. If you rely on method-scoped constraints to protect static content served by the default servlet, that protection was not behaving as written. This is the highest-impact finding among the six fixed in 9.0.119, it applies regardless of how you have clustering or rewrites configured, and it affects 8.5 as well. Affects 9.0.0.M1 to 9.0.118 (and 8.5.0 to 8.5.100). Fixed in 9.0.119.

CVE-2026-55955 | Low | EncryptInterceptor not protected against replay attacks

The EncryptInterceptor encrypts cluster traffic between Tomcat nodes. Its documentation claimed replay protection that the implementation did not actually provide. An attacker positioned to capture encrypted cluster messages could replay them. This only matters if you use the EncryptInterceptor for clustering, but if you do, a documentation-versus-reality mismatch is exactly the kind of gap that hides in plain sight. Affects 9.0.13 to 9.0.118 on the 9.0 line. On 8.5, it applies from 8.5.35 to 8.5.100, since the EncryptInterceptor arrived in the 8.5 branch at 8.5.35. Fixed in 9.0.119. This is the latest in a run of EncryptInterceptor findings (more on that below).

CVE-2026-53404 | Low | RewriteValve skips conditions in an OR chain

A logic bug in the RewriteValve. When rewrite conditions were chained with OR (the ornext flag), a match on the first condition caused later non-OR conditions to be skipped, and the rewrite succeeded anyway. If your rewrite rules double as security gates (a common pattern), a request could satisfy a rule it should not have. Affects 9.0.0.M1 to 9.0.118 (and 8.5.0 to 8.5.100). Fixed in 9.0.119.

CVE-2026-53434 | Low | Invalid CRLs ignored on the FFM connector

When the FFM connector (the OpenSSL integration via Java's Foreign Function and Memory API, also known as Project Panama) was configured with invalid CRLs, those CRLs were silently ignored, which meant certificates that should have been rejected could be accepted instead. This is a certificate-validation gap, and it continues a recent run of revocation-checking issues in Tomcat's FFM and OpenSSL path. It only affects FFM connector configurations. Affects 9.0.83 to 9.0.118. Fixed in 9.0.119.

This is the one finding in the batch that does not affect Tomcat 8.5. The FFM connector is a modern addition built on Java's Foreign Function and Memory API; it does not exist in the 8.5 line, which shipped only the legacy JNI and APR OpenSSL integration. With no FFM connector to misconfigure, there is no exposure on 8.5, and the affected floor begins at 9.0.83. It is a genuine "not affected" determination for 8.5, not a gap.

CVE-2026-55276 | Low | Logged effective web.xml is incomplete

Logic errors meant the logged effective web.xml left out special roles and empty authorization constraints. The runtime configuration itself was fine. The logged representation of it was not. That matters because the effective web.xml is exactly what engineers and auditors read to confirm what an application actually enforces. An incomplete log can send a security review down the wrong path. Affects 9.0.0.M1 to 9.0.118 (and 8.5.0 to 8.5.100). Fixed in 9.0.119.

CVE-2026-50229 | Low | XSS in the number guess example

Wildcard property mapping in the bundled examples webapp exposed properties that were meant to stay internal, opening an XSS hole in the number guess example. The examples webapp is not meant for production, but it gets left deployed more often than anyone likes to admit. If it is reachable, this is a live XSS vector. Affects 9.0.0.M1 to 9.0.118 (and 8.5.0 to 8.5.100). Fixed in 9.0.119.

‍

The pattern: the same components keep coming back

Several of these land on code that Tomcat has patched before.

The EncryptInterceptor has now been the subject of multiple findings: a documentation and DoS issue in 2022 (CVE-2022-29885), a padding oracle and a follow-up bypass earlier in 2026 (CVE-2026-29146 and CVE-2026-34486), and now a replay-protection gap (CVE-2026-55955). The RewriteValve has a similar track record across 2025 and 2026, including a rewrite rule bypass, a session fixation issue, and a directory traversal that could reach remote code execution, with CVE-2026-53404 the newest entry. The bundled examples webapp keeps producing XSS and DoS findings, and CVE-2026-50229 is the latest of those. And the Realm and authentication layer, where this batch's most serious issue lives, has its own history (CVE-2021-30640, CVE-2024-52316).

None of that is alarming on its own. It is normal for a mature, widely deployed server to see recurring scrutiny on its most security-sensitive components. The practical takeaway: if you run Tomcat clustering, directory-backed authentication, URL rewriting as a security control, or the examples webapp in production, those are the parts of your configuration most likely to generate the next finding too. Tracking "is this CVE patched" is not the same as tracking "is this component still under active scrutiny."

‍

Who is affected, and what to do

A couple of notes that keep this honest. The six fixed in 9.0.119 were disclosed as Tomcat 9.0.x fixes; the affected components exist on the 10.1.x and 11.0.x branches as well, and Apache typically ships parallel fixes there, so if you run those branches take the corresponding patched releases from the Tomcat 10 and Tomcat 11 advisories rather than assuming you are unaffected. CVE-2026-55957 spans all three supported branches and is fixed in 9.0.101, 10.1.37, and 11.0.5. And Apache does not sell commercial support for older branches itself, so once a branch goes EOL there is no first-party paid patch path. The options are to migrate or to bring in third-party support.

If you are on Tomcat 9.x

Upgrade to 9.0.119. It closes all seven, it is free, and it ships through the usual Apache download and Maven channels. The auth bypass (CVE-2026-55957) was fixed back in 9.0.101, so if you are on any 9.0.101 or later build you already have that one, but 9.0.119 is what you need for the rest of the batch. For teams on a current supported 9.0.x build, that is the right move and there is nothing to buy.

Worth keeping on your radar: Tomcat 9.x reaches end-of-life on March 31, 2027. The long-term supported path is Tomcat 10.1 or 11.0, both of which use the jakarta.* namespace. Moving from Tomcat 9 (javax.*) to 10 or 11 (jakarta.*) is not a drop-in version bump. The namespace change ripples through your application code and your dependencies, and for large Servlet-based applications that is a multi-quarter project, not a weekend. If you would rather not run that migration against a 2027 deadline, HeroDevs NES will extend security coverage for Tomcat 9.0 past its end-of-life date so you can plan the move on your own schedule.

If you are on Tomcat 8.5 or earlier

This is where the disclosure matters most. Six of the seven CVEs apply to Tomcat 8.5, and there is no 8.5 release that fixes any of them:

• CVE-2026-55957 (Important, JNDIRealm authentication bypass): 8.5.0 to 8.5.100, confirmed in the upstream Apache advisory
• CVE-2026-55956 (Moderate, default servlet security constraint bypass): 8.5.0 to 8.5.100
• CVE-2026-55955 (EncryptInterceptor replay): 8.5.35 to 8.5.100
• CVE-2026-55276 (incomplete effective web.xml logging): 8.5.0 to 8.5.100
• CVE-2026-53404 (RewriteValve OR-chain): 8.5.0 to 8.5.100
• CVE-2026-50229 (examples webapp XSS): 8.5.0 to 8.5.100

Only CVE-2026-53434 does not apply, because the FFM connector it targets was never part of 8.5.

Tomcat 8.5 reached end-of-life on March 31, 2024. After that date Apache stopped shipping 8.5 releases and, by its own statement, stopped checking security vulnerability reports against the 8.5 branch entirely. So for an Important authentication bypass that is confirmed to affect 8.5, there is no upstream fix coming, and the same is true for the four other applicable findings. Your scanner, meanwhile, will keep flagging these CVEs against the components you are running.

The clean fix is to move to a supported branch. But getting from 8.5 to 10 or 11 is the javax.* to jakarta.* rewrite described above, and for a large legacy application that is a serious effort. Upgrading to 9 first only buys you a version that hits its own EOL in 2027, with the namespace migration still ahead of you. That is two migrations back to back.

HeroDevs NES for Apache Tomcat 8.5 is built for exactly this gap. It delivers security-remediated Tomcat 8.5 packages through a drop-in, token-authenticated private registry, with minimal or no code changes in most environments, covering the six applicable CVEs above (CVE-2026-53434 is documented as not affected, so no remediation is required there). Scanner findings from tools like Snyk, Tenable, and OWASP Dependency-Check resolve, audit attestation is available for SOC 2, PCI DSS, ISO 27001, and similar frameworks, and your team gets the runway to plan one well-scoped migration instead of chasing EOL deadlines back to back. It buys back the engineering time you would otherwise spend keeping an unsupported server limping along.

‍

Taking action

If you are on Tomcat 9.0.x: upgrade to 9.0.119. Free, fast, done. On 10.1.x or 11.0.x, take 10.1.37 / 11.0.5 (or later) for the auth bypass and the matching releases for the rest.

If you are on Tomcat 8.5 or earlier, six of these seven CVEs apply to you, including an Important authentication bypass, with no upstream fix coming. That is precisely the situation HeroDevs NES is built for. We keep your current version secure and compliant while you plan the migration on your own timeline, not under scanner or audit pressure.

Talk to HeroDevs about NES for Apache Tomcat, or browse the HeroDevs Vulnerability Directory for per-CVE detail.

NES is a bridge to modernization, not a replacement for it.

‍

Frequently asked questions

Which CVE here should I worry about most? CVE-2026-55957. It is the only Important-rated issue, it is an authentication bypass in the JNDIRealm when GSSAPI authenticated bind is configured, and it is confirmed to affect EOL Tomcat 8.5 and 7.0. The other six are a Moderate default servlet bypass and five Low findings.

Which of these affect end-of-life Tomcat 8.5? Six of the seven. CVE-2026-55957, CVE-2026-55956, CVE-2026-55276, CVE-2026-53404, and CVE-2026-50229 affect 8.5.0 to 8.5.100. CVE-2026-55955 (EncryptInterceptor replay) affects 8.5.35 to 8.5.100, since that interceptor arrived in the 8.5 branch at 8.5.35. The only one that does not apply is CVE-2026-53434: the FFM connector it depends on was never part of Tomcat 8.5, which used the older JNI and APR OpenSSL integration instead.

Why is CVE-2026-55957 fixed in 9.0.101 when everything else is fixed in 9.0.119? The fix for the auth bypass shipped in the earlier 9.0.101, 10.1.37, and 11.0.5 releases. Its public advisory was published on June 29, 2026, the same day as the six findings fixed in 9.0.119, which is why they are grouped here. If you are on 9.0.101 or later you already have the auth bypass fix; you still need 9.0.119 for the other six.

I am on Tomcat 9. Which version do I install? 9.0.119. It is cumulative, so it closes all seven.

Do the JNDIRealm and GSSAPI conditions apply to us? Only if your Tomcat uses the JNDIRealm configured to authenticate binds using GSSAPI, typically LDAP or Active Directory authentication backed by Kerberos. If you do not use that configuration, CVE-2026-55957 does not apply, though the other findings may still apply depending on your setup.

Is the examples webapp really a risk? We would never ship that. Plenty of production Tomcat instances still have it deployed, often from an old base image or a default install nobody pruned. If it is reachable, CVE-2026-50229 is exploitable. It is worth confirming it is actually gone rather than assuming.

Related:

• Apache Tomcat 9 Security Page
• HeroDevs NES for Apache Tomcat
• HeroDevs Vulnerability Directory
• Tomcat Versions and Support Dates
• Tomcat April/May 2026 CVE Roundup