Apache Tomcat May 2026 Security Release: 7 CVEs Affect Tomcat 8.5

On May 10, 2026, the Apache Tomcat project released Tomcat 9.0.118, 10.1.55, and 11.0.22, with public disclosure of seven new CVEs on May 12. The release fixes a mix of moderate and low-severity issues spanning security constraint enforcement, digest authentication, AJP secret comparison, LockOutRealm case handling, WebSocket header exposure, HTTP/2 header validation, and WebDAV request handling.

Apache's published advisories list 9.x, 10.1.x, and 11.x as affected. The Tomcat 8.5 security page has not been updated since 8.5.99. But when you read the underlying CVE entries on the NVD, they clearly mark in the product status that version in 8.5 is exposed. Tomcat 8.5 reached end of life on March 31, 2024; no upstream patches will ship. Organizations still running Tomcat 8.5 are exposed to all seven CVEs with no fix from the Apache project.

This post breaks down each CVE in the May 2026 batch, documents what NVD records about 8.5 exposure for each, and lays out the remediation path for the EOL version.

‍

Why this matters for Tomcat 8.5 specifically

The pattern visible in this release is not new. Our April 2026 Tomcat roundup documented 10 CVEs disclosed against 9.x, 10.1.x, and 11.x where Tomcat 8.5 received no upstream coverage despite the affected components being present in the 8.5 codebase. Apache Tomcat 8.5 reached end of life over 14 months ago, but it remains in production at many organizations because of compliance dependencies, certified middleware stacks, and applications built against Servlet 3.1 / JSP 2.3 that have not yet been retargeted. The same EOL exposure compounds for teams running EOL Spring Boot 2.7, where Tomcat CVEs cascade into the embedded container. The Apache project's policy is to not list EOL versions on the per-branch security pages, even when the underlying CVE filings include those versions in the affected range.

For organizations subject to the EU Cyber Resilience Act (Article 14 reporting obligations begin enforcement September 2026) or DORA (Article 6 ICT risk management obligations in force since January 2025), shipping seven unpatched CVEs in a known-EOL component is increasingly a documented compliance exposure, not an internal risk discussion.

The result: a security engineer reading tomcat.apache.org/security-8.html sees no May 2026 entries and might reasonably conclude their 8.5 deployment is not affected. The NVD entries tell a different story.

‍

The seven CVEs at a glance

‍

CVE-2026-43515: Security constraints not correctly applied

Apache severity: Moderate CWE-285: Improper Authorization Affected (8.5 line): 8.5.0 through 8.5.100 (per NVD)

When a web.xml defines multiple <security-constraint> elements that target the same URL extension pattern with different HTTP method constraints, Tomcat only applied the first method constraint and silently ignored the rest. The practical impact: an administrator who defined two constraints, for example one for GET and one for POST against the same extension, would find that the second method's restrictions were never enforced. Requests that should have been blocked or required authentication could pass through under the rules of the first constraint instead.

This is the kind of misconfiguration-amplifier that is hard to detect through normal smoke testing because the application appears to behave correctly under the first constraint's path. The exposure surfaces only when traffic hits the second method.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

CVE-2026-43514: AJP secret compared in non-constant time

Apache severity: Low CWE-208: Observable Timing Discrepancy Affected (8.5 line): 8.5.0 through 8.5.100 (per NVD)

The AJP secret comparison used a non-constant-time string comparison, allowing an attacker on the same local network segment as the Tomcat instance to perform a timing attack to recover the secret one character at a time. 

The exploit requires local network adjacency, which is what keeps the severity rating low. But "local network" in modern deployments is a broad set: shared VLANs, container networks, and cloud VPCs all count. Any environment where the AJP secret is the only thing standing between an attacker and the AJP connector should treat this as actionable.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

CVE-2026-43513: LockOutRealm treats user names as case-sensitive

Apache severity: Low CWE-178: Improper Handling of Case Sensitivity Affected (8.5 line): 8.5.0 through 8.5.100 (per NVD)

The LockOutRealm tracks failed login attempts and locks the offending account after a configurable threshold. The bug: lockout tracking was case-sensitive on the user name, but the underlying realm (for example, a JNDI or DataSource realm with a case-insensitive backing store) might treat Admin and admin as the same account. An attacker could then bypass the lockout by varying capitalization: 5 attempts as admin, then 5 as Admin, then 5 as ADMIN, with no lockout triggered between cycles.

This is a brute-force amplifier, not a direct authentication bypass. Its severity depends on how the realm beneath LockOutRealm handles case, and on whether the account has a weak password. But for any deployment relying on LockOutRealm as a brute-force defense, the protection was less effective than the configuration implied.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

CVE-2026-43512: Digest authenticator accepts any unknown user with password "null"

Apache severity: Moderate CWE-592: Authentication Bypass Issues Affected (8.5 line): 8.5.0 through 8.5.100 (per NVD)

This is the standout in the batch. When Tomcat is configured with DIGEST authentication, any user not present in the configured realm is authenticated successfully if the request presents the literal password null. The root cause is a missing nil check in the digest comparison path: when the realm lookup returns no user, the comparison runs against a null password, and the digest of a request whose password component computes to null matches.

The practical exploit: hit any DIGEST-protected resource with arbitrary credentials and the password null. If the user is not in the realm (which is the common case for arbitrary attacker-chosen user names), authentication succeeds. From there, the attacker has whatever access the resource grants to "any authenticated user."

DIGEST authentication is less common in modern Tomcat deployments than BASIC or form-based auth, which is what keeps this rated Moderate rather than Critical. Any deployment that uses DIGEST should treat this as the priority CVE in the batch and act first.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

CVE-2026-42498: WebSocket authentication header exposure on redirect

Apache severity: Low CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Affected (8.5 line): 8.5.24 through 8.5.100 (per NVD)

When Tomcat's WebSocket client follows a redirect after authentication, it forwards the most recent authentication header to the redirect target host without checking whether the new host is the same as the original. An attacker controlling a redirect destination (through DNS hijacking, a misconfigured upstream, or a malicious endpoint) can capture credentials intended for a different host.

The exposure window is narrow: the Tomcat WebSocket client (not the server) is affected, and only in deployments where Tomcat itself initiates outbound WebSocket connections that might be redirected. For Tomcat as a server-side container, this is mostly not relevant. For applications using javax.websocket / jakarta.websocket client APIs from inside a Tomcat deployment to call out to other services, it is.

Note that 8.5 exposure begins at 8.5.24 (not 8.5.0), reflecting when the affected WebSocket client redirect handling was introduced.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

CVE-2026-41293: HTTP/2 request headers not validated

Apache severity: Low CWE-20: Improper Input Validation Affected (8.5 line): Yes (per NVD and component present and exposed in 8.5.x)

HTTP/2 request headers received by the connector were not validated for compliance with RFC 7540 framing rules before being exposed to applications through the Servlet API. The result: an application that reasonably assumed header values returned by HttpServletRequest.getHeader() would be specification-compliant could receive values containing characters that should have been rejected at the connector level. This becomes a vector where the application uses header values in security-sensitive contexts (cache keys, log fields, downstream HTTP calls) without sanitizing.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

CVE-2026-41284: Unbounded read in WebDAV LOCK and PROPFIND handling

Apache severity: Low CWE-770: Allocation of Resources Without Limits or Throttling Affected (8.5 line): Yes (component present and exposed in 8.5.x)

The WebDAV servlet did not enforce a limit on the request body size for LOCK and PROPFIND requests. Because both methods are available to unauthenticated users in default WebDAV configurations, an attacker can send an arbitrarily large XML body and force Tomcat to allocate memory to parse it. The classic resource-exhaustion DoS pattern.

The exposure requires WebDAV to be enabled in the deployment. Most Tomcat installations do not enable WebDAV by default, but those that do (often for content management, document sharing, or legacy integration) are exposed without authentication.

Apache fix: Tomcat 9.0.118, 10.1.55, 11.0.22

‍

Mitigation guidance

‍

Taking action

Seven CVEs landed in Apache's May 2026 release. Apache shipped patches for the three currently supported branches (9.0.x, 10.1.x, 11.0.x). Apache did not ship patches for Tomcat 8.5, which has been end of life for over a year. The Apache project's security page for the 8.x line has not been updated for any of these CVEs, but their own NVD filings confirm that 8.5 is in the affected range for the majority of them, and component analysis confirms the rest.

Tomcat 8.5 remains in production at many enterprises because of certified middleware dependencies, application code locked to older Servlet/JSP API levels, or organizational constraints that prevent migration to Tomcat 9 or 10.1 on the timelines the upstream project assumes. For those environments, NES for Apache Tomcat delivers a drop-in replacement for Tomcat 8.5 with remediations for all seven of these CVEs (and the prior CVE batches Apache has stopped patching on the 8.x line).

If you are running Tomcat 8.5 in production, the May 2026 release is a reminder that "no entry on the Apache security page" does not mean "not affected." It means the project has stopped tracking your version. The CVEs keep coming. NES is how organizations stay protected without an emergency migration.