91 Vulnerabilities Patched in Spring Application Framework

What happened

VMware's Spring Application Framework has received a patch batch closing 91 security vulnerabilities, pushing the year's total past 200 fixes in what security researchers are describing as a substantial acceleration in disclosed defects. The disclosure comes from SecurityWeek, which noted that the same framework saw only 16 patches in all of 2025 and 22 in 2024, making the current pace roughly ten times higher than recent annual norms.

This piece breaks down what the patch release covers, who runs software built on Spring and therefore needs to act, the steps a developer or operations team should take immediately, the general class of problems that accumulate in large Java application frameworks, and what details remain publicly unclear from the initial announcement. It is written for Java developers, platform engineers, DevSecOps teams, and anyone responsible for production services that depend on the Spring ecosystem.

VMware's Spring team released a coordinated set of patches addressing 91 vulnerabilities in the Spring Application Framework. That single release brings the total number of Spring vulnerabilities patched so far this year to more than 200, a figure that dwarfs the 16 patches issued throughout all of 2025 and the 22 issued throughout all of 2024 combined. The scale of the jump suggests either a sustained internal audit, an influx of external researcher reports, or both. Large consolidated patch releases of this kind are common when a vendor runs a structured security review program, often timed to responsible disclosure windows coordinated with the broader researcher community.

How it works

The numbers alone tell a story about risk accumulation. When a widely used platform goes years with relatively few public patches, it can indicate low researcher attention rather than low vulnerability density. The jump from roughly 16 to 22 patches per year to more than 200 in a single calendar year suggests that attention has now focused sharply on this codebase, and that the backlog of previously unreported or privately held issues is being cleared at an accelerated rate.

Spring is one of the most widely deployed Java application frameworks in the world, used by enterprises ranging from financial services firms to government agencies to large-scale internet platforms. Any organization running a Java application that depends on the Spring Framework, Spring Boot, Spring Security, Spring Data, or related Spring portfolio projects is potentially within scope for at least some subset of the 91 newly patched vulnerabilities. The exposure is not limited to a single module or a single deployment pattern.

Why it matters

Because Spring applications are frequently used as backend services handling authentication, database transactions, and API routing, vulnerabilities in the framework can sit at the center of an organization's attack surface rather than at its edge. Teams that use Spring-based microservices, containerized deployments, or cloud-native architectures built on Spring Boot are all potentially affected. Organizations that rely on third-party software vendors whose products are themselves built on Spring should also check whether those vendors have issued corresponding updates.

The immediate action for any team running Spring-based software is to inventory which Spring components and versions are in use across all environments, including development, staging, and production. That inventory should be compared against the official Spring security advisories published by VMware Broadcom, which list affected component versions alongside fixed versions for each patched vulnerability. Updating to the fixed versions is the primary remediation path, and teams should prioritize internet-facing services and those handling sensitive data first.

Beyond patching, teams should review their software composition analysis tooling and ensure it is configured to flag Spring dependencies automatically going forward. If a service cannot be patched immediately because of compatibility concerns or release cycles, temporary mitigations such as network-level controls or web application firewall rules may reduce exposure, but they do not substitute for applying the actual patches. After updating, running regression tests and verifying application behavior is important, since large patch batches occasionally introduce unintended breaking changes.

Who is affected

Application frameworks like Spring expose a broad API surface that developers use to wire together components, handle HTTP requests, manage database sessions, and enforce security policies. Each of those integration points is a potential location for vulnerabilities, including insecure deserialization, improper input validation, authorization bypass, server-side request forgery, and expression language injection. Frameworks that support dependency injection and proxy-based method interception are particularly complex, because security assumptions in one layer can be silently undermined by configuration choices in another.

The Spring ecosystem's modular design, while architecturally sound, means that vulnerabilities can exist in core modules, in security extensions, in data access layers, and in web binding components independently. An application that correctly uses Spring Security may still be exposed if it uses a vulnerable version of Spring Data or Spring Web. The breadth of the 91-vulnerability patch batch reflects that complexity, and it underscores why treating each module's version as an independent security concern rather than relying on a single framework version number is important practice.

What to watch next

The SecurityWeek report does not specify how the 91 vulnerabilities are distributed by severity, by Spring subproject, or by the class of weakness involved. Without that breakdown, it is not possible to determine from public information alone which subset of the patches is most urgent for any given application. VMware Broadcom's own security advisories are the authoritative source for that detail, and teams should consult them directly rather than relying on aggregated news coverage.

It is also not publicly clear from the available information how many of the 91 vulnerabilities were reported by external researchers versus discovered internally, whether any have been exploited in the wild prior to the patch release, or whether coordinated disclosure timelines mean that technical details will be published on a delay. Until those details emerge, defenders should treat the entire patch set as requiring prompt attention and avoid waiting for proof-of-concept exploit code to appear before prioritizing upgrades.