CVE-2026-41720

What it actually does

Spring LDAP authentication strategies in the affected version ranges can treat a bind attempt with a non-empty username and an empty or null password as successful instead of rejecting it before contacting LDAP. In LDAP, a simple bind with a distinguished name but no password may be interpreted as an unauthenticated bind by some directory servers or configurations. If the application relies on the affected Spring LDAP authentication flow and does not independently block empty passwords, an unauthenticated remote attacker may be able to authenticate as a known user without knowing that user’s password. The impact is authentication bypass with potential access to data and actions permitted to the impersonated account; availability is not directly affected.

Why it matters to the business

Applications using affected Spring LDAP versions for login may allow attackers to access accounts without valid credentials if empty-password login attempts are accepted by the authentication path. This can lead to unauthorized access to sensitive business data, account takeover, fraudulent transactions or configuration changes, and downstream compromise of systems that trust the application’s authentication. The CVSS score is high, but current exploitation signals are low: EPSS is approximately 0.0026, has remained flat over 30 days, no public exploit maturity is reported, and it is not listed in CISA KEV or ransomware use as of the provided data.

How an attack unfolds

An attacker first identifies an internet-facing or reachable application that uses Spring LDAP for authentication and is running one of the affected versions. The attacker then obtains or guesses a valid username, user ID, email address, or LDAP distinguished name. Instead of providing a real password, the attacker submits the username with an empty password, null password field, or otherwise blank credential value through the login interface or authentication API. If the vulnerable Spring LDAP authentication strategy passes that bind attempt through and the backing LDAP server permits or returns success for an unauthenticated bind, the application may treat the attacker as authenticated as that user. The attacker can then access application functions and data according to the privileges of the impersonated account, potentially escalating impact if administrative or highly privileged usernames are targeted.

How to fix it

Upgrade Spring LDAP to a fixed, non-affected release for the major/minor line in use. Based on the affected ranges, versions newer than 2.4.4, 3.2.17, 3.3.7, and 4.0.3 should be reviewed against the vendor advisory and applied where available. If immediate upgrade is not possible, add explicit application-side validation that rejects null, missing, whitespace-only, or zero-length passwords before any LDAP bind is attempted. Also configure the LDAP directory to disallow unauthenticated simple binds where supported, and ensure authentication code does not treat an unauthenticated bind as a successful user login. Review custom DirContextAuthenticationStrategy usage, authentication filters, login controllers, and API gateways for alternate paths that may accept blank credentials.

How to confirm the fix worked

Confirm remediation by checking the resolved Spring LDAP library version in build manifests and runtime artifacts, such as Maven dependency trees, Gradle dependency reports, SBOMs, container images, and deployed application packages. Verify that no deployed artifact includes Spring LDAP 2.4.0-2.4.4, 3.2.0-3.2.17, 3.3.0-3.3.7, or 4.0.0-4.0.3. Perform a controlled negative authentication test against each login path: submit a known valid username with an empty password, omitted password, null JSON password value, and whitespace-only password, and confirm the request is rejected before LDAP bind succeeds. Review LDAP server configuration to confirm unauthenticated simple binds are disabled or not accepted. If dependency upgrades are made, run regression tests for normal login, failed login, password reset, service account bind, and multi-factor authentication flows.

Typical attack path

1. Identify an application that uses Spring LDAP-based authentication and is reachable over the network.
2. Determine whether the application version or dependency tree includes Spring LDAP 2.4.0-2.4.4, 3.2.0-3.2.17, 3.3.0-3.3.7, or 4.0.0-4.0.3.
3. Collect or guess valid usernames, email addresses, or LDAP distinguished names through public sources, error messages, enumeration, or prior compromise.
4. Submit a login or authentication request with a valid non-empty username and an empty, omitted, or null password value.
5. Rely on the vulnerable authentication strategy and LDAP unauthenticated-bind behavior to receive an authenticated application session.
6. Use the resulting session to access data or perform actions available to the impersonated user.
7. Repeat against higher-privilege accounts if username discovery and application behavior allow it.

How to detect it

There are no universal file, process, or network indicators unique to this vulnerability; detection depends on application, web, identity, and LDAP logging. Review application authentication logs for successful logins where the password parameter was empty, null, omitted, or had zero length. If request logging is available, look for POST requests to login or authentication endpoints with a populated username field and an empty password field, while taking care not to expose or retain actual passwords. Review LDAP directory logs for successful simple bind operations that include a bind DN or username but no password, anonymous or unauthenticated bind semantics, or zero-length credential indicators. Correlate these events with application session creation, access tokens, role assignments, and subsequent sensitive actions. Prioritize suspicious successes for privileged accounts, dormant accounts, service accounts, and users with no corresponding MFA challenge or normal login telemetry. Also look for repeated login attempts using many usernames with blank passwords, which may indicate probing. Because exploitation may appear as a normal successful login after the bypass, behavioral analysis of source IP, user agent, time of day, geolocation, and account history is important.

What your security team should do

• Inventory applications and services that use Spring LDAP, including transitive dependencies in Java applications, containers, and packaged products.
• Prioritize externally reachable, privileged, administrative, customer-facing, and SSO-adjacent applications that perform LDAP authentication.
• Upgrade affected Spring LDAP versions to vendor-confirmed fixed releases or rebuild applications with non-affected dependency versions.
• Implement or verify server-side validation that rejects empty, null, omitted, or whitespace-only passwords before LDAP authentication is attempted.
• Disable LDAP unauthenticated simple binds at the directory service level where operationally feasible.
• Hunt authentication logs for successful logins where the submitted credential length is zero, the password field is missing, or request metadata indicates a blank credential submission.
• Review recent successful logins to sensitive accounts, especially accounts with administrative roles, from unusual IP addresses, user agents, geographies, or impossible-travel patterns.
• Add regression tests and CI dependency checks to prevent reintroduction of affected Spring LDAP versions or acceptance of blank passwords.
• Because EPSS is currently low and there is no KEV listing, handle as high-priority preventive remediation rather than confirmed mass exploitation, unless local exposure or suspicious authentication activity is found.