Spring Framework Security Guide (2026)

Spring Framework is the backbone of enterprise Java. Through Spring Boot it underpins a vast portion of production Java services — web APIs, batch jobs, messaging systems, and everything in between — and it arrives in builds via Maven and Gradle across effectively every large Java shop. Its breadth is its risk surface: Spring does data binding, request routing, expression evaluation (SpEL), URL parsing, and static resource serving, and each of those subsystems has produced real vulnerabilities. The most famous, Spring4Shell, briefly threatened to become "the next Log4Shell."

The notable historical CVEs

Spring Framework's security history spans remote code execution, path traversal, and SSRF. Real, published advisories include:

• CVE-2022-22965 (Spring4Shell) — a remote code execution flaw in Spring MVC/WebFlux data binding, exploitable on JDK 9+ when a specific set of conditions were met (notably WAR deployment on Tomcat). Fixed in 5.3.18 and 5.2.20.
• CVE-2016-1000027 — unsafe Java deserialization in RemoteInvocationSerializingHttpMessageConverter; the affected remoting support was ultimately removed in Spring Framework 6.0.
• CVE-2023-20860 / CVE-2023-20861 — a security-bypass in URL pattern matching and a SpEL denial-of-service, respectively, fixed across the 5.3.x/6.0.x lines.
• CVE-2024-22243 / CVE-2024-22259 / CVE-2024-22262 — a series of open-redirect and SSRF issues in UriComponentsBuilder caused by inconsistent URL parsing, fixed incrementally through the 5.3.x and 6.1.x lines.
• CVE-2024-38816 / CVE-2024-38819 — path traversal in the functional web endpoints (RouterFunctions / WebFlux.fn) when serving static resources, allowing access to files outside the intended directory. Fixed in the 5.3.x/6.1.x service releases.

The pattern: Spring's convenience features — automatic binding, flexible URL parsing, functional static-file routing — repeatedly turned into attack surface when they processed attacker-controlled input in ways the developer did not anticipate.

Common misuse and risks

• Running an unpatched minor version. Spring ships security fixes in point releases; teams that pin to an old 5.3.x or 6.0.x and never bump miss the traversal and SSRF fixes above.
• Passing user input into SpEL. Spring Expression Language is powerful enough to execute arbitrary code. Building SpEL expressions from user input is a direct RCE path and should never happen.
• Serving static resources from user-influenced paths. The 2024 traversal CVEs show how functional endpoints mapping requests to files can escape the intended root if paths are not normalized.
• Trusting UriComponentsBuilder output for security decisions. Inconsistent parsing between components led to open redirects and SSRF; do not use it to validate a host allowlist without care.
• Assuming Spring Security covers Spring Framework CVEs. They are separate projects; a hardened auth layer does not patch a framework deserialization or traversal bug.

How to use Spring Framework safely

Set the version floor: run a current, supported release — the latest 6.1.x (or 6.2.x) for modern apps, or the latest 5.3.x if you are still on the 5.x line. These carry the Spring4Shell, traversal, and SSRF fixes. Prefer managing versions through the Spring Boot BOM so the whole stack stays aligned.

Additional guidance:

• Never build or evaluate SpEL expressions from untrusted input. If you must template, use a sandboxed, non-executing engine.
• Constrain data binding with @InitBinder allowlists (setAllowedFields) so clients cannot bind unexpected properties — a general hardening that also mitigated Spring4Shell-style abuse.
• Normalize and validate any file path derived from a request before serving static content, and keep resource roots outside your application code.
• Treat UriComponentsBuilder results as untrusted for redirect and SSRF decisions; validate the final host against an allowlist explicitly.
• Deploy on a current JDK and keep the servlet container (Tomcat/Jetty) patched — several Spring CVEs depend on the runtime environment.

How to monitor Spring Framework with SCA and reachability

Spring is transitive nearly everywhere in a Java build, so a version-based scanner will flag its CVEs in every service. Reachability analysis is what tells you whether a given CVE is live: does a request reach the vulnerable data-binding path, the functional static-resource endpoint, or a SpEL evaluation with untrusted input?

Safeguard's software composition analysis resolves your full Spring dependency graph — the framework version pulled in by Spring Boot starters included — and adds call-path reachability so exploitable findings rise above dormant ones. Griffin AI explains each finding and the minimal safe upgrade, and when a patched release exists, autonomous auto-fix opens a tested pull request that bumps the Spring modules together via the BOM. Developers run the same analysis locally and in CI with the Safeguard CLI.

Bring continuous, prioritized dependency analysis to your Java services — get started free or read the documentation.

Frequently Asked Questions

Which Spring Framework version is safe in 2026?

Run a current, supported release: the latest 6.1.x or 6.2.x for modern applications, or the latest 5.3.x if you remain on the 5.x line. Those carry the fixes for Spring4Shell (CVE-2022-22965) and the more recent path-traversal (CVE-2024-38816/38819) and SSRF (CVE-2024-22243 and related) issues. Manage the version through the Spring Boot BOM to keep the stack aligned.

Was Spring4Shell as dangerous as Log4Shell?

It was serious but far more conditional. Spring4Shell (CVE-2022-22965) required JDK 9+ and a specific deployment shape — notably a WAR on Tomcat — to be exploitable, whereas Log4Shell needed only that you log an attacker-controlled string. Both are fixed in current releases; the practical takeaway is the same, patch promptly and keep an accurate inventory.

Is Spring Framework the same as Spring Security?

No. Spring Framework is the core application framework; Spring Security is a separate project for authentication and authorization. Hardening Spring Security does not patch a Spring Framework deserialization, traversal, or SSRF CVE, so you must track and update both.

What is the most dangerous Spring misuse pattern?

Evaluating Spring Expression Language (SpEL) built from user input. SpEL can execute arbitrary code, so constructing expressions from untrusted data is a direct route to remote code execution. Never interpolate request data into a SpEL expression.

How do I know which Spring CVE actually affects my service?

Use reachability-aware SCA. It traces whether requests in your application reach the vulnerable subsystem — data binding, functional static-resource serving, or SpEL evaluation — with attacker-influenced input, so you can prioritize the CVEs that are genuinely exploitable rather than every advisory naming Spring.