When the BOM Freezes: The Risk of Hidden Dependencies in EOL Spring Applications

When organizations assess the risks of end-of-life (EOL) software, attention usually focuses on the framework itself. Once a version reaches EOL, it no longer receives vendor updates, security fixes, or bug patches. While that's certainly a concern, it's often only part of the story.

Modern Spring applications are built on a much broader ecosystem. Alongside Spring Framework and Spring Boot, most production environments rely on technologies such as Spring Data, Spring Batch, Spring Cloud, database drivers, messaging clients, logging frameworks, serialization libraries, and dozens of other dependencies. Understanding how those components are managed is critical to understanding the security implications of running EOL software.

Learn About OpenLogic Spring LTS   Get Help With a Spring Migration

What is the Spring Boot BOM and Why Does It Matter?

A core part of the Spring ecosystem is the Spring Boot Bill of Materials (BOM), which provides a curated set of dependency versions that have been tested to work together.

Rather than requiring developers to select and validate individual versions of components such as Jackson, Tomcat, Hibernate, Kafka clients, or Spring portfolio projects, the BOM establishes a known-good combination. This approach simplifies development, reduces compatibility issues, and helps teams move faster.

However, the tradeoff is that many organizations have limited visibility into the full dependency graph underneath their applications because those decisions are being managed for them.

What Happens to the Spring Boot BOM When a Release Reaches End of Life?

When a Spring Boot release reaches end of life, the BOM effectively stops evolving. The dependency versions it manages remain frozen at the last supported release.

The software itself does not disappear, and applications may continue running successfully for years. However, the broader security landscape continues to change. Vulnerability researchers continue discovering issues, maintainers continue releasing fixes for supported versions, and new attack techniques continue to emerge.

Over time, this creates a widening gap between the dependencies running in production and the versions actively receiving maintenance. The longer an organization remains on an EOL stack, the more opportunity there is for that gap to grow.

The Operational Burden of Managing a Frozen BOM

Once a Spring Boot BOM stops receiving updates, responsibility for monitoring and maintaining dependencies shifts to the application team. When new vulnerabilities are disclosed, teams must determine whether they're affected, evaluate compatibility, test dependency overrides, and document results for security and compliance requirements.

It’s also worth pointing out that while CVEs are often the most visible consequence, they're not the only concern. New Java releases, database drivers, application servers, and supporting libraries continue to evolve as well, creating potential compatibility, performance, and operational issues that compound over time, adding to the challenge of maintaining EOL versions.

How a Frozen BOM Creates Security Risks for Spring Applications

If your application only used a small subset of the Spring Framework, dependency injection, MVC, and little else, the risks associated with a frozen BOM would be more limited. But most production applications rely on far more than the core framework.

Modern Spring environments commonly include Spring Data, Spring Batch, Spring Cloud, database drivers, messaging clients, serialization libraries, and other dependencies managed through the Spring Boot BOM. When that BOM freezes at EOL, those dependencies stop advancing as well, even as new vulnerabilities continue to be discovered and fixed in supported versions.

Here are some CVEs impacting legacy Spring Data, Spring Cloud, and Spring Batch: 

Spring Data

Spring Data sits directly on top of the data access layer, making it a critical part of many enterprise applications. It is also closely tied to database drivers, query execution, and expression evaluation mechanisms.

CVE-2022-22980 was a critical Spring Data MongoDB vulnerability involving Spring Expression Language (SpEL) injection in @Query and @Aggregation annotated repository methods when user input was not properly sanitized. Vulnerabilities in this class have continued to surface in later versions of Spring Data components, including MongoDB, Redis, KeyValue, and REST modules. Organizations running EOL Spring Data releases may not receive fixes for newly discovered variants.

In vulnerable implementations, unsanitized SpEL expressions could potentially be evaluated at runtime, creating opportunities for attackers to influence query execution.

Spring Cloud

Spring Cloud expands the application footprint beyond the framework itself into gateways, service discovery, configuration management, and distributed systems infrastructure.

Several vulnerabilities have emerged in these components over the years, including:

• CVE-2020-5427 and CVE-2020-5428, involving SQL injection vulnerabilities in Spring Cloud Task and Spring Cloud Data Flow query functionality.
• CVE-2021-22113, a sensitive-header bypass issue affecting Spring Cloud Netflix Zuul.
• CVE-2025-41253, a Spring Cloud Gateway SpEL injection vulnerability that could expose environment variables and system properties when certain actuator endpoints were enabled.

Spring Batch

Spring Batch has experienced relatively few direct security vulnerabilities compared to other Spring projects. However, it illustrates an equally important lesson about dependency risk.

CVE-2026-47881 involved a denial-of-service vulnerability in Spring Batch's FlatFileItemReader. A specially crafted input file could trigger excessive CPU and memory consumption during multi-line record processing, potentially causing batch jobs to stall or run out of memory. Unlike vulnerabilities that target application business logic, this issue arose from how a core framework component handled malformed input. It serves as another reminder that an application's security posture depends not only on the code developers write, but also on the behavior and resilience of the framework components and dependencies it relies upon.

Related Resources

• Patching Spring CVEs in the Age of AI 
• Managing EOL Spring Vulnerabilities 

Transitive Dependency Risk in the Spring Ecosystem

What ties the above examples together is not simply the presence of known vulnerabilities. It's the broader issue of transitive dependency exposure.

As previously noted, most organizations don't just run Spring; they run ecosystems built on Spring. As software ages, security and maintenance concerns often emerge from the layers beneath the framework itself: libraries, drivers, connectors, and supporting components that applications depend on every day.

This is why dependency management should be viewed as a security discipline rather than a maintenance task. Understanding which components are in use, which are still supported, and which have fallen out of support is an essential part of managing application risk.

How OpenLogic Spring LTS Solves This Issue

Spring Long-Term Support from OpenLogic is designed to address this reality, extending coverage beyond Spring Framework and Spring Boot to include key ecosystem projects such as Spring Data, Spring Cloud, and Spring Batch. Just as importantly, OpenLogic helps organizations maintain the dependency ecosystem that surrounds those frameworks. Rather than leaving teams with a frozen BOM as community support ends, OpenLogic continues maintaining and validating supported dependency versions, allowing customers to keep using the BOM-driven version management model they already rely on. 

This means security fixes and compatibility updates can be delivered through the broader Spring stack while preserving stability and reducing the need for disruptive upgrades. When a vulnerability or breaking change requires a larger version jump, OpenLogic provides guidance on upgrade paths and modernization planning, helping organizations maintain secure, stable applications while moving to newer platforms on their own timeline.

Additional Resources

• Blog - Tanzu Spring vs. Open Source Spring: Which Is Better for Enterprise Development?
• Blog - Spring Boot 4.0 Migration Guide
• Video - The Spring Upgrade Dilemma: Move Fast or Stay Stable?
• Blog - Planning Your Next Spring Boot Upgrade
• Blog - Preparing for Spring Framework 6.2 EOL