Spring Vulnerabilities in 2026: What to Check in Your Java Stack

In August 2026, the developers of Spring — the Java application framework now maintained by Broadcom — released updates patching 91 vulnerabilities across the framework and related projects in the ecosystem. Security firm Sonatype analyzed those patches and estimated the flaws reach more than 200,000 software components. For any company running core systems on Java and Spring, this is not just another piece of technical news: it is a direct signal about the real state of its attack surface.

What the research found

Of the 91, one was rated critical in Spring’s own advisory: CVE-2026-59270, in Spring Security’s embedded UnboundID LDAP server, which would let an attacker authenticate and modify entries in the in-memory directory. Sonatype flagged a second one it rates as critical, CVE-2026-59285, a remote code execution issue in Spring for GraphQL. More than a dozen were classified as high severity, with scenarios ranging from XSS and information disclosure to remote code execution, denial of service, and security bypasses. Affected projects include Spring Security, Spring AI, Cloud Config, Data REST, Integration, Reactor Core, Reactor Netty, AMQP and Batch — components many applications treat as safe simply because they ship with the framework.

The change of scale is the real story

August’s number is not an isolated spike. More than 200 vulnerabilities have been patched in Spring so far in 2026, against 16 in all of 2025 and 22 in 2024. The increase is attributed to Broadcom’s use of artificial intelligence to find flaws in its own code. Put differently: Spring did not suddenly become insecure — it is being reviewed with far more powerful tools, and what was previously invisible is now surfacing. For the teams consuming the framework, the practical consequence is the same: the pace at which patches must be applied has changed scale, and a process designed for two or three advisories a year no longer keeps up.

Why it weighs more in regulated sectors

In banking, insurance, pharma, or any industry with compliance requirements, an unpatched vulnerability stops being purely technical: it becomes a legal and reputational risk. Regulators expect evidence of active vulnerability management, not good intentions. And there is concrete precedent that these flaws get exploited: Spring vulnerabilities have been used in real attacks, including Spring4Shell, and several appear in CISA’s catalog of known exploited vulnerabilities.

The real problem is not the vulnerabilities; it is response time

Many organizations find out late that they are running outdated versions because they have no continuous visibility into their dependencies. When patches are already available — as they are here — the risk window is not set by the attacker; it is set by how long the organization takes to notice and act. Treating a system as "finished" rather than sustaining it with ongoing maintenance is one of the riskiest decisions a technology team can make today.

What to do about it

Auditing dependencies regularly, automating patch management, and running a continuous maintenance process are concrete, achievable steps. An up-to-date component inventory, automatic alerts when an advisory affects your own stack, and a deployment window reserved for security patches cover most of the problem. At Sagant we work with companies running Java/Spring systems in production on exactly this: modernization and secure maintenance, without slowing the business down.

Conclusion

Vulnerabilities will keep appearing; that is normal in any active software ecosystem. What makes the difference is having a serious process to detect and resolve them in time. If you are not certain which version of Spring is running in your production environment today, this is a good moment to check. Let’s talk.