When Authentication Fails, It Fails Open
On October 20, Apache Tomcat published a batch of vulnerability fixes. The headline issue is CVE-2026-101296, rated Important: when the JNDI Realm is configured with a non-GSSAPI SASL authentication mechanism, a critical step is missing from the authentication flow, and an attacker can pass authentication without supplying the correct password. The phrase worth noting in the official advisory is more telling than the CVE number itself — "bind credential validation fails open": when validation fails, the door falls in the direction of open.
How it works
In Tomcat, the component responsible for "who are you and is the password right" is called a Realm. JNDIRealm is one type, storing the user list in an LDAP directory server. During authentication, Tomcat uses the username and password to perform a bind against the directory server — a successful bind means the directory server has verified the password on your behalf. SASL is LDAP's authentication negotiation framework with several mechanisms: GSSAPI (i.e., Kerberos) is one, alongside non-GSSAPI mechanisms like DIGEST-MD5. The flaw sits on this non-GSSAPI path: the step that validates the bind credentials either never runs, or its result is ignored — and the code's default action is not to stop and reject, but to continue onward, authentication granted.
The first lesson of security code is fail closed: in any uncertain situation, reject. This vulnerability is its mirror image — fail open.
A familiar predecessor
There is prior history. In June this year, Tomcat fixed a sibling flaw in the same component (CVE-2026-55957) — a "missing critical authentication step" on the GSSAPI path. That plugged one route; on September 14, someone reported the exact same problem on the non-GSSAPI SASL path — the same step missing again. Both were closed together on October 20. The same class of "no validation, let it through" appearing twice in six months, on two authentication mechanisms of the same component.
Scope and mitigations
The affected range is notable: every release from the first build of three version lines — 11.0.0-M1 through 11.0.26, 10.1.0-M1 through 10.1.60, and 9.0.0.M1 through 9.0.122. In other words, the flaw is as old as JNDIRealm's SASL support itself, touched and reported for the first time in over a decade.
There is a natural buffer in the blast radius: the default configuration uses the in-memory Realm, and most JNDI+LDAP deployments use simple bind rather than SASL — so the population of affected environments is smaller than the headline suggests. But for environments using JNDIRealm with SASL, this is a door for an unauthenticated remote attacker straight to protected resources and management interfaces. Upgrade priority leaves no room for debate.
Fixed versions: 11.0.27, 10.1.61, 9.0.123.
The rest of the batch
Three "crosstalk" issues were disclosed in the same batch and are worth reading together:
- AJP response confusion (CVE-2026-103119): a large non-blocking write can split a response body across the current and next request; data from the previous response may leak to the next one.
- HTTP/2 request/response confusion after async errors (CVE-2026-101356): object recycling and reuse can cause responses to cross between users.
- HTTP/2 trailer header cross-request pollution (CVE-2026-88041): trailer information from the previous request leaks into the next.