91 Spring CVEs in a Single Day: Inside the August 2026 Batch
Understanding the shift in Spring project security disclosures and what this record-breaking batch means for your Java dependency tree.
On August 20, 2026, the Spring project published 91 security advisories at once. One Critical, 17 High, 55 Medium, 18 Low, all on Spring's own severity scale, spanning 20 projects across the portfolio. For comparison, all of 2025 produced 16.
Spring is the default application framework for enterprise Java, so the reach here is wide by definition. The batch touches Spring Framework, Spring Security, Spring Data REST, Spring Integration, Spring Cloud, Spring for GraphQL, Spring AI, and the Reactor libraries that sit underneath much of it. If you run Java in production, some part of this is in your dependency tree whether you declared it or not.
This post covers what's actually in the batch: why 91 landed in one day, which findings carry the most weight, and which ones reach back into versions that no longer receive open source patches. Most of these CVEs aren't in NVD yet, so if your scanner is quiet this week, it isn't because you're fine. It's because the feed hasn't caught up.
August CVE Count (91) is 5.7x all of 2025 Spring CVEs
This isn't a backlog dump. It's how the Spring project structures disclosure now, coordinated release windows across the whole portfolio rather than one project at a time. What changed is how much lands inside each window. The Spring security team has been open about why: AI-assisted code analysis is now running systematically across the projects they maintain.
Spring used to receive about 6.5 security reports a month. In April 2026, it received 482. Month over month, 2026 looks like this.
CVE-2026-59270, the only Critical in the batch
Spring Security's UnboundIdContainer starts an embedded LDAP server for applications that need a directory to authenticate against. It registers an administrative credential without restriction and binds the listener to every available network interface. Anyone who can reach that port authenticates using the well-known administrative bind DN, then reads or modifies entries in the in-memory directory, including the user records the application authenticates against.
The precondition is narrow and worth stating plainly rather than inflating. You have to be using UnboundIdContainer, either configured directly or through Spring Boot auto-configuration via spring.ldap.embedded.*, and the listener port has to be reachable from wherever an attacker sits. Plenty of teams use the embedded container only under a test profile. Some ship it into environments where it's reachable, usually without meaning to. If that's you, triage this one first.
Spring rates it Critical. It reaches further back than anything else in the batch, affecting 4.2.x, 5.7.0 to 5.7.25, 5.8.0 to 5.8.27, 6.4.0 to 6.4.18, 6.5.0 to 6.5.11, 7.0.0 to 7.0.6, and 7.1.0.
CVE-2026-59285, unsafe deserialization in Spring for GraphQL
Spring for GraphQL's pagination support performs unsafe deserialization when processing paginated queries, classified as CWE-502. A crafted request against a paginated Connection field can reach code execution. Four conditions have to hold together: the application uses Spring for GraphQL, it uses Jackson 2.x for JSON deserialization, it exposes paginated Connection fields, and the classpath carries classes that can be leveraged during instantiation. That's a real stack of preconditions, and it's also a completely ordinary Spring for GraphQL setup.
Spring rates it High. Affects 2.0.0 to 2.0.4. Three more GraphQL advisories in the same batch reach the 1.0.x, 1.3.x, and 1.4.x lines.
Also worth knowing about: CVE-2026-59318, a privilege escalation in Spring AI's tool-calling path reachable through prompt injection. Spring rates it Medium, and it's one of the few in this batch that has already been scored in NVD.
The CVE findings that reach older versions
The three above land on lines that are still actively maintained. These reach further back, into versions that stopped receiving open source patches some time ago. If your applications sit on an older Spring line, these are the ones to look at first.
CVE-2026-47849, Spring Data REST JSON Patch
Spring Data REST blocks modification of @Id and @Version properties on PUT and merge-patch requests. The RFC 6902 JSON Patch path, served at application/json-patch+json, never received the equivalent guard. An authenticated client with PATCH access can rewrite the identifier on a record and land it on top of a record belonging to someone else, and can rewrite the version property to defeat optimistic locking.
The outcome is horizontal privilege escalation plus silent data loss, from a caller who is legitimately authenticated and doing something your access control layer considers allowed. The advisory narrows the scope: an application is affected only where the exposed entity's identifier or version property is visible to Jackson's deserialization model, meaning it has a public setter and isn't excluded with @JsonIgnore. Where that holds, nothing in the request looks anomalous.
This is also the second JSON Patch guard failure in Spring Data REST this year, following CVE-2026-41728 in June, which matters if your team resolved that one and assumed the code path had been hardened. Spring rates it High. Affects 3.7.20 and earlier, 4.0.0 to 4.4.15, 4.5.0 to 4.5.12, 5.0.0 to 5.0.6, and 5.1.0. The 3.7.x line is the Spring Boot 2.7 generation.
CVE-2026-59324, cross-request header leakage in Spring Integration
When an integration flow uses .fluxTransform() with an asynchronous or reordering function that emits raw payloads, reply headers get copied from whichever message was most recently consumed upstream rather than from the message being processed. Under concurrency on a shared FluxMessageChannel subscription, one user's response is delivered onto another user's reply channel, carrying replyChannel, errorChannel, correlationId, and any propagated security or tenant headers with it.
That's cross-tenant data delivery in a multi-tenant deployment, and it's a reportable event under SOC 2 CC7.3 and CC7.4 regardless of how the CVE ends up scored. It also fails quietly. Nothing errors, nothing retries, and the logs look clean. They always do.
The advisory identifies a source-level mitigation that doesn't require an upgrade, typing the argument to fluxTransform() as Function<? super Flux<Message<I>>, ? extends Publisher<Message<O>>> fluxFunction. That's a signature change and a rebuild, not a configuration property. Spring rates it High. Affects 5.5.21 and earlier, 6.4.0 to 6.4.12, 6.5.0 to 6.5.10, 7.0.0 to 7.0.5, and 7.1.0.
CVE-2026-59316, Spring Authorization Server consent page
The default consent page in Spring Authorization Server renders user-controlled values from the OAuth2 authorization request without HTML entity encoding. Injected script executes in the browser of a user who is in the middle of granting authorization, which is about the worst place in an OAuth2 flow to have script execution. Applications that configure a custom consent page through OAuth2AuthorizationServerConfigurer.authorizationEndpoint(c -> c.consentPage(...)) are not affected.
The same defect on the newer Spring Security 7.x line is tracked separately as CVE-2026-47877. Spring rates both High. CVE-2026-59316 affects Spring Authorization Server 1.4.0 to 1.4.11 and 1.5.0 to 1.5.8.
Two more Spring Security findings in this batch land on lines that are past their open source support window and deserve a look if you're running them: CVE-2026-47841, a WebAuthn user verification bypass that triggers when sessions are serialized through a distributed store, and CVE-2026-41707, a DPoP proof replay made possible by flooding the server to evict a legitimate jti from the replay-prevention cache.
Spring Boot 3.5 reached end of life two months ago
Timing matters here. Spring Boot 3.5 reached the end of its open source support window on June 30, 2026, which put the entire Spring Boot 3.x generation outside the community patch stream. This batch is the first disclosure of real size to land after that date.
Spring Boot 4.0 reaches end of open source support in December, 2026, and 4.1 runs to July 31, 2027. If you're scoping a migration off 3.5 right now, 4.1 is the target that carries you into 2027. Treating 4.0 as the endpoint means scoping the same project twice.
The migration isn't a version bump either. For more details see What the Migration Really Takes here.
What to do now
Find out what you actually run. Most organizations don't have a clean inventory of which Spring lines their applications consume, especially across a portfolio of any size. Run your SCA tool against the full dependency tree, not your top-level pom.xml or build.gradle. Spring Security, Spring Data REST, and Spring Integration usually arrive through Spring Boot starters and shared platform BOMs rather than a direct declaration.
Check the advisories directly rather than waiting on your scanner. Most of the 91 aren't indexed in NVD or OSV yet. The Spring security page has all of them today, with affected ranges and fix versions per advisory.
Work out where your version lines stand. Spring publishes a fix for every affected line, but the fixes don't all ship the same way, and which one applies to you depends on whether that line is still inside its open source support window. If your applications sit on Spring Boot 2.7 or 3.x, or on Spring Security 5.x or 6.x, that question is worth answering before you triage individual CVEs.
If you're running end-of-life Spring and want to talk through where you stand, get in touch with our team. We track this batch closely and can walk you through what applies to your stack.
Frequently asked questions
Why don't these CVEs show up in my scanner?
Most SCA tooling reads NVD and OSV. As of publication only a handful of the 91 have been indexed in NVD and none appear in OSV, so a clean scan right now reflects a reporting delay rather than an all clear. The advisories are published on Spring's own security page and that's the authoritative source until indexing catches up.
Are all 91 CVEs present in every affected version?
No. Each advisory carries its own version ranges and its own preconditions, and most of the batch is Medium or Low severity affecting a specific component under a specific configuration. Work from the Spring advisory index and filter to the products in your dependency tree.
How do I know if I'm running the embedded LDAP container?
Search your configuration for spring.ldap.embedded properties and your code for UnboundIdContainer. If either is present outside a test-only profile, CVE-2026-59270 applies to you. Confirm which network interfaces the listener actually binds to in your deployed environment rather than assuming localhost.
Does running end-of-life Spring affect compliance?
PCI DSS 4.0 Requirement 6.3.3 requires critical and high-security patches to be installed within one month of release, and FedRAMP ties RA-5 remediation to 30 days for high-risk findings. SOC 2 CC7.1 requires detection and monitoring for newly discovered vulnerabilities, and NIS2 Article 21(2)(e) and DORA require vulnerability handling as part of risk management without prescribing fixed clocks. A finding on a line with no open source patch available can't be closed by upgrading within that line, which turns it into a persistent open item rather than a scheduled one.
Is another batch like this coming?
Based on the trend the Spring team has published, yes. Monthly disclosure volume has moved up by an order of magnitude since March 2026 and the scanning program that produced it is ongoing.
Related:
Resources
View All Articles
