org.springframework:spring-web is the core Spring Framework module that provides the HTTP and web infrastructure most Spring applications depend on, and keeping it patched is one of the highest-leverage things you can do for Java application security. If you run any Spring MVC or Spring WebFlux application, spring-web is almost certainly in your classpath, either declared directly or pulled in transitively by Spring Boot starters. Because it sits directly on the request-handling path, a vulnerability here tends to be reachable and serious, as the Spring4Shell incident demonstrated.
What org.springframework:spring-web provides
The spring-web artifact is the foundational web module of the Spring Framework. It contains the HTTP client and server abstractions, multipart handling, the RestTemplate and reactive WebClient plumbing, filters, and the shared web context support. It is the layer that both org.springframework:spring-webmvc (the servlet-stack MVC framework) and spring-webflux (the reactive stack) build on top of. In practice you rarely add spring-web by hand; you add a starter like spring-boot-starter-web, and Maven or Gradle resolves spring-web, spring-webmvc, and their peers to matching versions.
A typical direct declaration looks like this:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>6.1.6</version>
</dependency>
If you are on Spring Boot, prefer letting the Boot dependency management BOM pick the version rather than pinning spring-web yourself, so all Spring modules stay aligned.
Spring4Shell: the defining spring-web CVE
The most consequential vulnerability associated with the Spring web stack is CVE-2022-22965, known as Spring4Shell. It is a remote code execution flaw disclosed on 31 March 2022, carrying a CVSS v3 base score of 9.8 (critical). The root cause is data binding: an attacker could manipulate Spring's property binding to reach ClassLoader properties and write a malicious file to disk, achieving RCE.
According to the NVD entry and Spring's own advisory, exploitation required a specific combination of conditions:
- JDK 9 or higher (the flaw depended on a
getModuleaccessor introduced then). - A
spring-webmvcorspring-webfluxdependency. - Deployment as a traditional WAR on Apache Tomcat (the classic exploit chain targeted a Tomcat-specific class loader).
Spring shipped fixes in Framework versions 5.3.18 and 5.2.20; versions before those in the 5.3.x and 5.2.x lines were affected. If you are on any current 6.x release you are well past this, but legacy 5.x deployments still turn up in scans, and the WAR-on-Tomcat pattern is common in enterprise estates.
Do not confuse Spring4Shell with CVE-2022-22963, a separate RCE in Spring Cloud Function disclosed around the same time and fixed in Spring Cloud Function 3.1.7 and 3.2.3. They were reported in the same window and are frequently conflated, but they live in different artifacts.
Why spring-web is worth prioritizing
Two structural facts make spring-web CVEs high priority. First, reachability: this code runs on the request path, so a flaw is usually exploitable from the network rather than buried in an unused utility. Second, ubiquity: because starters pull it in transitively, a single vulnerable spring-web version can sit inside dozens of services in an organization, and teams often do not realize which apps are affected until they inventory the dependency graph. An SCA tool such as Safeguard can flag a vulnerable spring-web transitively even when no one declared it directly.
Verify a CVE claim before you act on it — check the NVD entry and the official Spring advisory for the exact affected ranges rather than trusting a secondhand summary. Version ranges get misquoted constantly, and "affects Spring 5.x" is far too broad to drive a remediation plan.
spring-web and spring-webmvc: keep them aligned
Because spring-web and org.springframework:spring-webmvc are released in lockstep as part of the Spring Framework, a version mismatch between them is a red flag. If a scan shows spring-web at one version and spring-webmvc at another, something has overridden the managed version — often a stray direct dependency or an old library dragging in an older Spring. Run a dependency tree to see who is pulling what:
# Maven
mvn dependency:tree -Dincludes=org.springframework:spring-web
# Gradle
./gradlew dependencyInsight --dependency spring-web
Resolve mismatches by upgrading the offending parent or adding a dependency management entry, not by force-pinning spring-web in isolation.
Keeping the dependency patched
The durable answer is process, not a one-time upgrade. A few practices that hold up:
- Track the Spring Framework version through the Spring Boot BOM so spring-web, spring-webmvc, and the rest move together.
- Subscribe to Spring Security advisories and the GitHub Security Advisory feed for the
org.springframeworkgroup. - Fail CI on new critical or high findings in the Spring modules rather than deferring them to a quarterly cleanup.
- Keep an SBOM so that when the next spring-web CVE lands, you can answer "which services are affected" in minutes.
Spring-web 6.0.0 raised the baseline to Java 17 and Jakarta EE 9+, so if you are still on 5.x you are also on an older JDK and servlet API. Planning that migration pays down security debt across the board, not just for a single CVE.
FAQ
What is org.springframework:spring-web used for?
It is the core web module of the Spring Framework, providing the HTTP client and server abstractions that spring-webmvc and spring-webflux build on. Almost every Spring web application depends on it directly or transitively.
Is spring-web affected by Spring4Shell?
Spring4Shell (CVE-2022-22965) affected the Spring Framework web stack in 5.3.x before 5.3.18 and 5.2.x before 5.2.20, under specific conditions including JDK 9+ and a WAR deployment on Tomcat. Upgrading to the fixed releases, or any current 6.x version, resolves it.
How is spring-web different from spring-webmvc?
spring-web is the shared foundation; org.springframework:spring-webmvc is the servlet-stack MVC framework built on top of it. They ship as part of the same Spring Framework release and should always be on the same version.
How do I keep spring-web secure?
Let the Spring Boot BOM manage the version so all Spring modules stay aligned, monitor official Spring advisories, fail CI on new high-severity findings, and maintain an SBOM so you can identify affected services quickly when a new CVE is published.