CVE-2026-65905: Apache Tomcat DIGEST Auth Bypass Vulnerability

CVE-2026-65905 Overview

CVE-2026-65905 is an authentication bypass by capture-replay vulnerability in the Apache Tomcat DIGEST authenticator. Under specific conditions tied to the replay window, an attacker who captures a valid DIGEST-authenticated request can replay it to bypass authentication. The flaw is classified under CWE-294: Authentication Bypass by Capture-replay and affects multiple current and end-of-life Tomcat branches. Apache addressed the issue in Tomcat versions 11.0.25, 10.1.58, and 9.0.121.

Critical Impact
A remote, unauthenticated attacker who observes a valid DIGEST authentication exchange can replay the request to gain access to protected resources without credentials.

Affected Products

Apache Tomcat 11.0.0-M1 through 11.0.24
Apache Tomcat 10.1.0-M1 through 10.1.57
Apache Tomcat 9.0.0.M1 through 9.0.120
End-of-life branches also affected: 8.5.0 through 8.5.100 and 7.0.30 through 7.0.109

Discovery Timeline

2026-08-25 - CVE-2026-65905 published to the National Vulnerability Database (NVD)
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-65905

Vulnerability Analysis

The vulnerability resides in Apache Tomcat's DIGEST authenticator, which implements HTTP Digest Access Authentication. Digest authentication is designed to prevent replay attacks by using server-issued nonces combined with a client-side nonceCount counter that must increase with each request. Tomcat tracks these counters within a bounded replay window controlled by the windowSize configuration.

The defect occurs when a client issues a DIGEST-authenticated request whose nonceCount sits on the upper boundary of the replay window before windowSize requests have been made. In that state, the boundary request remains replayable once while its nonceCount stays within the window. An attacker observing that request on the network can resubmit it to authenticate as the original user.

Because the flaw sits in the authentication path, successful exploitation grants access to any resource protected by DIGEST authentication on the vulnerable Tomcat instance. Exploitation requires the attacker to capture a legitimate authenticated request, typically through network interception or a compromised intermediary.

Root Cause

The root cause is incorrect boundary handling in the replay-window logic of the DIGEST authenticator. The window comparison permits a nonceCount at the upper boundary to be accepted a second time when the counter table has not yet been fully populated. This violates the single-use guarantee that Digest authentication depends on for replay resistance.

Attack Vector

Exploitation is network-based and requires no privileges or user interaction. The attacker must observe a valid DIGEST-authenticated HTTP request, which is possible on unencrypted channels or through an on-path position. The captured request is then replayed to the Tomcat server once, while the associated nonceCount remains within the replay window.

No public proof-of-concept or exploit code is currently available. Refer to the Apache Security Mailing List Thread and the Openwall OSS-Security Discussion for the vendor's technical description.

Detection Methods for CVE-2026-65905

Indicators of Compromise

Duplicate HTTP requests to the same protected URI carrying identical Authorization: Digest headers, including matching nonce, nc, cnonce, and response values.
Successful authentication events from unexpected source IPs immediately following a legitimate DIGEST authentication from a different address.
Access log entries showing back-to-back 200/2xx responses for the same authenticated resource with unusual timing patterns.

Detection Strategies

Enable verbose access logging on Tomcat and inspect the Authorization header to identify repeated nc (nonceCount) values against the same nonce.
Deploy TLS inspection or application-layer logging at a reverse proxy (for example, Apache HTTPD or Nginx) fronting Tomcat to correlate authentication headers with client identity.
Alert on any DIGEST authentication response reuse across different TCP sessions or source addresses within a short time window.

Monitoring Recommendations

Ingest Tomcat access logs and application logs into a centralized analytics platform to correlate replayed authentication attempts across hosts.
Monitor for anomalous session establishment on DIGEST-protected endpoints, particularly from source addresses that have never previously authenticated.
Track version and patch status of all Tomcat instances to identify unpatched hosts running vulnerable 9.x, 10.1.x, or 11.0.x builds.

How to Mitigate CVE-2026-65905

Immediate Actions Required

Upgrade Apache Tomcat to 11.0.25, 10.1.58, or 9.0.121 as appropriate for your deployment branch.
Inventory all Tomcat instances, including embedded deployments, and confirm which authenticators are enabled in server.xml and web.xml.
Retire or upgrade end-of-life 7.0.x and 8.5.x installations, which will not receive security fixes.
Enforce HTTPS for all endpoints that use DIGEST authentication to reduce the feasibility of on-path request capture.

Patch Information

The Apache Tomcat project has released fixed versions 11.0.25, 10.1.58, and 9.0.121. Details are available in the Apache Security Mailing List Thread and the Openwall OSS-Security Discussion. Users on unsupported 8.5.x or 7.0.x branches must upgrade to a supported release.

Workarounds

Switch protected applications from DIGEST authentication to a stronger mechanism such as FORM authentication over TLS, client certificate authentication, or an SSO integration.
Terminate TLS in front of Tomcat and restrict access to DIGEST-protected resources to trusted network segments until patching is complete.
Reduce the exposure window by lowering the DIGEST nonceValidity value in the authenticator configuration so nonces expire more quickly.

bash

# Example: replace the DIGEST authenticator with a FORM authenticator over TLS
# in $CATALINA_BASE/conf/server.xml (Context element)

<Context>
  <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
         disableProxyCaching="true"
         securePagesWithPragma="false"/>
</Context>

# Ensure the connector enforces TLS
<Connector port="8443"
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           SSLEnabled="true"
           scheme="https"
           secure="true"
           defaultSSLHostConfigName="secure">
  <SSLHostConfig hostName="secure" protocols="TLSv1.3,TLSv1.2"/>
</Connector>