Safeguard
Vulnerability Analysis•

CVE-2026-59270: Admin Credential in Spring Security Embedded LDAP

CVE-2026-59270: the Spring Security embedded UnboundID LDAP server registers an admin credential on all interfaces. Upgrade to 7.1.1, 7.0.7 or 6.5.12.

Safeguard Security Team
5 min read

CVE-2026-59270 is a critical flaw (CVSS 9.4) in Spring Security. The embedded UnboundID LDAP server (UnboundIdContainer) always registers an administrative credential and listens on all network interfaces. Upgrade to 7.1.1, 7.0.7, 6.5.12, 6.4.19, 5.8.28 or 5.7.26, depending on your line.

What's affected

  • Spring Security 7.1.0.
  • Spring Security 7.0.0 to 7.0.6.
  • Spring Security 6.5.0 to 6.5.11, 6.4.0 to 6.4.18, 5.8.0 to 5.8.27 and 5.7.0 to 5.7.25.
  • Fixed: 7.1.1 and 7.0.7 (open source), and 6.5.12, 6.4.19, 5.8.28, 5.7.26 for enterprise support customers. Enterprise only builds 7.1.0.1 and 7.0.6.1 also exist.
  • Preconditions from Spring: the app uses UnboundIdContainer, directly or through Spring Boot auto-configuration with spring.ldap.embedded properties, and the listener port is reachable from the attacker.

How to check if you're exposed

List your Spring Security version. With Maven run mvn dependency:tree -Dincludes=org.springframework.security. With Gradle run ./gradlew dependencies and search for spring-security. Then check whether the embedded server is in use: grep -rn "UnboundIdContainer\|spring.ldap.embedded" src/ config/. Finally list listening ports with ss -ltn on the host to see if an LDAP port is open to other machines.

To find this library in your own projects, paste a manifest or lockfile into the free in-browser dependency scan at gold.safeguard.sh/scan. Gold lists known CVEs for the packages it finds, and its reachability analysis helps you separate code that actually calls a vulnerable function from code that only ships it.

What to do now

  1. If you do not need the embedded LDAP server in a deployed environment, remove it. It is meant for tests and demos.
  2. Upgrade Spring Security to the fixed version for your line.
  3. Bind or firewall the LDAP port so only localhost can reach it.
  4. If it was reachable, review directory contents for changes and treat anything it served as untrusted.
  5. Check non production environments too, since test setups often use the embedded server.

Once the new version is in, run the same dependency or version check again and keep the output with your change record. Lockfiles drift, and a rebuilt image can quietly pull the old version back in, so check the artifact you actually deploy and not only the source tree.

Why it matters

The record classes this as CWE-863 (Incorrect Authorization). Spring says the container unconditionally registers a well known administrative bind DN and listens on every interface. Anyone who can reach the port can authenticate as that account and read or change entries in the in-memory directory.

The damage depends on what your app trusts the directory for. If login or role lookups run against that LDAP server, an attacker who edits entries can change who the app thinks a user is. If it is only a test fixture, exposure is limited to the test data.

Two habits help. Treat test conveniences as production risks when they can end up on a shared network. And inventory your framework versions, because a single flaw hits several release lines at once, as here. The CISA KEV flag is false.

Spring Security includes an embedded LDAP server so that developers can test directory login without installing anything. Spring Boot can start it from configuration properties, which makes it easy to enable and easy to forget. The advisory says the flaw bites when the app uses the container, directly or through auto-configuration, and the port can be reached.

The practical audit has three steps. First, find every service that depends on Spring Security, and the version of each. Second, search configuration and code for the container class and the embedded LDAP properties. Third, for each hit, find out where it runs and which networks can reach its port. A service that starts it only inside a unit test run is not exposed in production, while one that starts it in a shared development or staging cluster may be.

Fixed versions depend on your release line. Open source users have 7.1.1 and 7.0.7. The advisory lists 6.5.12, 6.4.19, 5.8.28 and 5.7.26 as available through enterprise support only, along with enterprise builds of the 7.x lines. If you run an older line without a support contract, plan a move to a supported line, because the record names no other fixed route for those versions.

If you cannot upgrade immediately, the advisory states no further mitigation, but its own preconditions suggest the safest interim step: make sure the listener port is not reachable from anywhere except the host itself, and switch off the embedded server where it is not needed.

Try it yourself

Knowing which Spring Security version each service pulls in is the first step. This demo shows a dependency inventory.

Click through it at your own pace, or open it full screen.

Quick check

Does this affect every Spring Security app?

No. Spring says it applies when the app uses UnboundIdContainer and the port is reachable.

Why are some fixes enterprise only?

The Spring advisory lists open source fixes only for 7.1.x and 7.0.x. Other lines are listed under enterprise support.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.