CVE-2026-65905: Tomcat DIGEST Auth Replay Bypass

Most Tomcat CVEs that hit critical severity are the kind that let an unauthenticated attacker walk straight in. CVE-2026-65905 is a different shape of bug: a real authentication bypass, rated 9.8, that only works if an attacker is already positioned to capture a specific request at a specific moment. It’s worth understanding precisely because the CVSS score and the actual exploitability tell two different stories, and both matter for how urgently you patch.

What’s actually broken

Tomcat’s DIGEST authenticator implements HTTP Digest Access Authentication, an older scheme where the client proves it knows a password without sending it in plaintext, using a server-issued nonce and a client-supplied nonce count (nc) to prevent replay. The server is supposed to reject a request that reuses a nonce count it’s already seen within the current window.

The bug: if a client makes a DIGEST-authenticated request with a nonce count sitting at the upper boundary of that replay window, before windowSize requests have actually been made, Tomcat lets that specific request be replayed exactly once while the nonce count still falls inside the window. An attacker who has captured that one request, meaning they had visibility into the traffic in the first place, can resend it and get treated as authenticated, without ever knowing the password behind it.

That’s a genuine bypass. It’s also a narrow one. It requires:

1. An attacker with the ability to capture the exact request in transit (so TLS is either absent, misconfigured, or already compromised on that connection).
2. That request to land specifically on the upper edge of the nonce-count window rather than anywhere else in a normal request stream.
3. A single replay opportunity, not a repeatable skeleton key.

Why the CVSS score and the real-world risk diverge

A 9.8 signals network-exploitable, no privileges required, high impact on confidentiality and integrity, the same bracket as an unauthenticated RCE. But CVSS scores the technical mechanics of a flaw, not the practical difficulty of setting up the conditions to trigger it. This bug needs an attacker who’s already capturing traffic, which is a precondition most other 9.8s (an internet-facing RCE, an auth bypass reachable with just a crafted HTTP request) don’t share.

That distinction matters for triage. If your Tomcat instances all sit behind TLS terminated correctly and DIGEST auth isn’t in your configuration at all, this is a straightforward patch-on-schedule item, not a fire drill. If you do run DIGEST auth on a connection where TLS might be weak or where an attacker could plausibly be on-path (an internal network segment you don’t fully trust, a load balancer misconfiguration), it deserves faster attention. Getting that read right is the same judgment call we walked through in how vCenter’s recent critical bugs actually got exploited: understand the actual attack surface before deciding how fast to move, rather than reacting to the score alone.

Who’s actually running DIGEST auth

This is the detail that will resolve most of the anxiety around this CVE for most teams: almost nobody configures DIGEST authentication anymore. It predates modern practice by a couple of decades, and most Tomcat deployments today use one of:

• FORM-based authentication, where the app owns its own login page and session handling.
• Container-managed security backed by an external identity provider (OIDC, SAML) via a filter or valve, not Tomcat’s built-in Realm mechanisms.
• Authentication terminated upstream, at a reverse proxy, API gateway, or load balancer, with Tomcat trusting a validated identity header behind it.

If your web.xml doesn’t declare <auth-method>DIGEST</auth-method> and your Tomcat Realm configuration doesn’t reference digest-based credential storage, this CVE has nothing to act on in your deployment. Confirm it rather than assume it, since legacy internal admin consoles and older Java EE-style apps are exactly the kind of thing that quietly still has DIGEST configured from a decade-old setup nobody’s revisited.

What to actually do

1. Check whether DIGEST auth is configured anywhere in your stack. Grep web.xml and Realm configuration across every app, not just the ones you remember, since forgotten legacy admin panels are the likely culprits.
2. If it’s not configured, patch on your normal cycle. Upgrade to Tomcat 11.0.25, 10.1.58, or 9.0.121 whenever your next maintenance window allows, no need to treat this as urgent if DIGEST isn’t in use.
3. If it is configured, prioritize the patch and check your TLS posture on that path. The bug’s real-world risk hinges entirely on whether an attacker could capture the traffic in the first place; a solid TLS setup with no on-path attacker access closes most of that gap even before you patch.
4. Flag any Tomcat 8.5.x or 7.0.x instances for retirement. They’re affected by this bug and won’t get an official fix, and EOL branches carrying unfixed critical CVEs are a liability independent of this specific issue.
5. Don’t skip the patch just because the exploit path is narrow. Narrow today doesn’t mean narrow after someone publishes a cleaner writeup of the exact nonce-count timing needed.

DIGEST auth is a legacy scheme, but legacy doesn’t mean absent. If a codebase audit or dependency review is on your team’s list this quarter, checking for exactly this kind of dormant, half-forgotten configuration is worth the hour it takes.