CVE-2026-59270: Spring Security Embedded LDAP Admin DN Exposure

On August 20, 2026, the Spring Security team disclosed CVE-2026-59270, a Critical vulnerability in Spring Security's embedded UnboundID LDAP server. The advisory references a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L, which computes to a base score of 9.4, Critical. The flaw (CWE-1327, exposure of a resource to the wrong control sphere, combined with a use of hard-coded credentials) lives in UnboundIdContainer: the container unconditionally registers a well-known administrative bind DN and binds its listener to all available network interfaces instead of loopback. Any attacker who can reach the LDAP port can authenticate as uid=admin,ou=system and read or modify the in-memory directory. Spring Security 7.1.1 and 7.0.7 carry the OSS fix. Versions 5.7.x, 5.8.x, 6.4.x, 6.5.x, and the affected 7.0/7.1 releases below the fix line are past their OSS support window with no OSS fix available.

Affected and unsupported? See NES for Spring.

‍

What is CVE-2026-59270?

CVE-2026-59270 is a network exposure and hard-coded credential flaw in org.springframework.security.ldap.server.UnboundIdContainer, the embedded in-memory LDAP server Spring Security ships for testing and development. You get it either by wiring the container directly or, more commonly, through Spring Boot auto-configuration via the spring.ldap.embedded.* properties.

The problem is two decisions made together in the container's startup path.

First, the container registers an administrative credential every time it starts. The bind DN uid=admin,ou=system and its password are well-known: they are in the framework source, so they are effectively public.

Second, the listener binds to all interfaces. UnboundID's InMemoryListenerConfig.createLDAPConfig("LDAP", this.port) defaults to binding on every available network interface rather than localhost. So the embedded directory, which is meant to be a throwaway fixture reachable only from the test JVM, is instead listening on the host's routable addresses.

Put the two together and any process that can open a TCP connection to that port can bind as the admin DN. From there it can read every entry in the directory or write new ones, which in a test or CI context often means user records, group memberships, and whatever else the LDAP-backed auth flow depends on.

‍

Severity and exploit conditions

The advisory labels this Critical and references a CVSS 3.1 vector. There is no separate NVD analysis yet (the CVE was not indexed in NVD or OSV at the time of writing), so the CNA vector below is authoritative. Recomputing the referenced vector independently yields a 9.4 base, Critical.

‍

The prerequisites are specific and they matter for triage. Two conditions both have to hold. The application has to actually run UnboundIdContainer, whether wired directly or pulled in through spring.ldap.embedded.* auto-configuration. And the listener port has to be reachable from the attacker's network position, meaning it is not already fenced off to localhost by an external firewall or network policy.

That second condition is where most of the real-world nuance sits, and the "Who is affected?" section below spells it out.

‍

What an attacker can do

An attacker who can reach an exposed UnboundIdContainer listener can:

• Bind as the administrator without credentials of their own. The DN uid=admin,ou=system and its password ship in the framework, so the attacker just presents them. There is no brute force and no credential theft step.
• Read the entire in-memory directory. Every entry the application loaded into the embedded server, user records, group memberships, and any attributes attached to them, is readable once bound as admin.
• Modify or inject directory entries. Write access means an attacker can alter existing entries or add new ones. In an environment where an auth flow trusts that directory, that can mean planting an account, changing a group membership, or rewriting an attribute a downstream check relies on.
• Pivot from a supposedly-isolated fixture. The embedded server is treated as disposable test scaffolding, so it rarely sits behind the same controls as a production directory. On a shared CI runner, a developer VM on a flat network, or a staging box with a routable address, that assumption is the whole vulnerability.

The blast radius depends entirely on what the reachable directory is wired into. A throwaway integration test on a laptop that is never reachable is not a real exposure. A CI runner on a shared network that seeds the embedded directory with realistic user data is.

‍

Who is affected?

Two things have to be true for this to reach you. You have to be running UnboundIdContainer, and its listener port has to be reachable from an untrusted network position. If your embedded LDAP server is confined to localhost by a firewall or network policy, or you do not use the embedded server at all, this specific bug does not reach you.

That said, do not lean on "it is only a test server" to skip the upgrade. The container turns up in CI pipelines, shared dev environments, and staging setups far more often than teams track, and any of those on a routable address is exposed. The score is Critical for a reason: the credential is public and the bind is unauthenticated.

‍

The two current lines, 7.1 and 7.0, have OSS fixes: upgrade to 7.1.1 or 7.0.7 and you are done. Both shipped to Maven Central on August 20, 2026 alongside the disclosure.

Everything below that is the harder case. Spring Security 6.5 reached OSS end of life on June 30, 2026, and 6.4 on December 31, 2025, per the Spring Security support timeline. The 5.7 and 5.8 lines went OSS EOL back in 2023. For all four of those lines there is no free open-source fix. The only patched builds are behind a paid vendor tier, which does not help a team that cannot or will not take a commercial upgrade path.

‍

Mitigation guidance

‍

Upgrading within a supported line (7.0.x or 7.1.x) is a patch-level change and carries no API break. Moving off an EOL line is a larger exercise that can surface transitive dependency conflicts and behavior changes across the Spring stack, which is the gap remediated end-of-life builds are meant to close.

‍

Related CVEs

CVE-2026-59270 is the latest in a run of Spring Security issues where a default configuration does something quieter and more dangerous than it looks. The directory entries and deep dives worth reading alongside it:

• CVE-2026-22732: Spring Security silently drops HTTP security headers under specific configurations. We covered the mechanics in our analysis of the header-dropping bug.
• CVE-2026-22752: a Critical cluster in Spring Authorization Server covering XSS, SSRF, and privilege escalation. See the full breakdown.
• CVE-2025-22232: authentication bypass in Spring Cloud Config, another case where a default behavior undercut an auth boundary. Details in our Spring Cloud Config writeup.

For the broader pattern of how fast Spring CVEs accumulate against EOL branches, see what the Spring numbers say about open source security.

‍

Taking action

If you run Spring Security 7.1.0 or any 7.0.x through 7.0.6, upgrade to 7.1.1 or 7.0.7. Both are OSS, both are on Maven Central, and both are patch-level changes with no API break. Before you close the ticket, confirm what interface your embedded LDAP listener actually binds to in CI and staging, because that is where this bug hides.

The harder decision belongs to teams on 5.7, 5.8, 6.4, or 6.5. Those lines are past OSS end of life, so no free fix is coming. The vulnerable UnboundIdContainer code sits in those releases exactly as it did in the supported lines, and every new Spring Security CVE widens the gap between what upstream patches and what you are running. Migrating major Spring versions is rarely a same-sprint job, and until you finish, an EOL line accrues each new disclosure with no advisory-backed fix to point at.

NES for Spring delivers drop-in replacement builds that resolve vulnerabilities on end-of-life Spring Security lines without forcing a framework migration you are not ready for. See NES for Spring to confirm coverage for your version, or talk to our team about scoping an end-of-life Spring estate.