Vulnerability Directory | CVE-2026-41720

Overview

Spring LDAP is a Java library that simplifies LDAP operations, providing a template-based abstraction (LdapTemplate and LdapClient) over the JNDI LDAP API for authentication, search, and directory manipulation. A high-severity vulnerability (CVE-2026-41720) has been identified in Spring LDAP that allows an authentication bypass when a non-empty username is paired with an empty or null password. The DirContextAuthenticationStrategy implementations fail to reject this bind shape, which corresponds to the LDAP unauthenticated bind described in RFC 4513 section 5.1.2. Many directory servers treat such a request as an anonymous bind and return success, so callers believe authentication succeeded even though no password was ever verified.

Per OWASP: authorization bypass, also described as broken access control, occurs when an application fails to properly enforce restrictions on what an authenticated or unauthenticated user is permitted to do. In an authentication-bypass scenario such as this one, an attacker is able to obtain a security context that the application treats as a successfully authenticated principal without supplying valid credentials, undermining the trust boundary that the authentication step is meant to establish.

This issue affects versions >=2.3.0 <=2.3.8, >=2.4.0 <=2.4.4, >=3.2.0 <=3.2.17, >=3.3.0 <=3.3.7, and >=4.0.0 <=4.0.3 of Spring LDAP.

‍

Details

Module Info

Product: Spring LDAP
Affected packages: spring-ldap-core
Affected versions: >=2.3.0 <=2.3.8, >=2.4.0 <=2.4.4, >=3.2.0 <=3.2.17, >=3.3.0 <=3.3.7, >=4.0.0 <=4.0.3
GitHub repository: https://github.com/spring-projects/spring-ldap
Published packages: https://central.sonatype.com/artifact/org.springframework.ldap/spring-ldap-core
Package manager: Maven
Fixed in:
NES for Spring LDAP
Spring LDAP 3.3.8, 4.0.4 (OSS)

Vulnerability Info

When an application authenticates against a directory, Spring LDAP delegates the construction of the JNDI bind environment to a DirContextAuthenticationStrategy implementation. The three built-in strategies, SimpleDirContextAuthenticationStrategy, DigestMd5DirContextAuthenticationStrategy, and DefaultTlsDirContextAuthenticationStrategy, populated the bind credentials without checking whether a userDn was supplied alongside an empty or null password.

According to RFC 4513 section 5.1.2, a simple bind request that carries a distinguished name but a zero-length password is an unauthenticated bind. Many directory servers, including common Active Directory configurations, accept this request and return a success result equivalent to an anonymous bind. Because the strategy did not reject the request, the higher-level APIs propagated the server's success response back to the caller. As a result, a call such as LdapTemplate.authenticate(...) returned true, and direct AbstractContextSource or ContextSource usage produced a context, even though no password had actually been validated. An attacker who knows or can enumerate a valid username could therefore be treated as authenticated by supplying a blank password.

The fix adds an explicit guard at the start of the bind-environment setup in each affected strategy. When a userDn is present but the password is empty, an AuthenticationException is thrown so that callers observe the same exception type they would for any other authentication failure:

if (StringUtils.hasLength(userDn) && !StringUtils.hasLength(password)) {
    throw new AuthenticationException(
            new javax.naming.AuthenticationException("password must be provided when userDn is set"));
}

‍

The guard relies on StringUtils.hasLength to treat both null and zero-length passwords as missing credentials. Applications that legitimately require the unauthenticated-bind behavior can configure a custom DirContextAuthenticationStrategy. The canonical fix commit is available on GitHub, and the nearest OSS maintenance-branch fix (3.3.8) is also published.

‍

Mitigation

The 3.3.x and 4.0.x lines received public OSS fixes in Spring LDAP 3.3.8 and 4.0.4. The 2.3.x, 2.4.x, and 3.2.x lines did not receive a public OSS fix.

We recommend the following actions:

Upgrade to a supported, patched version of Spring LDAP. For OSS users this means 3.3.8 or 4.0.4 or later. Do not attempt to apply your own patch to an unsupported release.
For users who must remain on the 2.3.x, 2.4.x, or 3.2.x lines, or who otherwise cannot upgrade, HeroDevs Never-Ending Support (NES) provides a patched build. The fix has been backported to the NES 2.3.x, 2.4.x, and 3.2.x lines, delivering the same empty-password guard without requiring a major-version migration.

‍