Spring4Shell Vulnerability: What It Is and How to Fix It

Spring4Shell usually refers to CVE-2022-22965, a remote-code-execution vulnerability in Spring Framework data binding. The documented exploit scenario applies to Spring MVC or Spring WebFlux applications running on JDK 9 or later, with Apache Tomcat, WAR packaging, and an affected Spring Framework version. Check the actual framework version and deployment details, update to a vendor-fixed release or your product vendor’s patch, and investigate logs separately for possible compromise.

The vulnerability is serious: the National Vulnerability Database (NVD) assigns it a CVSS 3.x base score of 9.8 (Critical) and lists it in CISA’s Known Exploited Vulnerabilities Catalog. Those ratings do not determine whether a particular installation is exposed or compromised. [NVD entry for CVE-2022-22965]

What is Spring4Shell?

Spring4Shell is the common name for CVE-2022-22965, which Spring describes as “Spring Framework RCE via Data Binding on JDK 9+.” In the documented exploit path, request data binding can reach sensitive internals of a Spring MVC or Spring WebFlux application. Microsoft’s analysis describes a proof of concept that changed Tomcat access-log settings to write a JSP web shell into a path accessible to the application. [Spring security advisory] [Microsoft analysis and detection guidance]

This is a vulnerability with specific prerequisites for the published exploit scenario; it does not mean every Spring application is exploitable. Conversely, not matching one prerequisite should not be treated as proof that a system is safe from every possible exploit path. Spring’s advisory notes that other ways to exploit the underlying vulnerability may exist.

Which versions are affected?

Spring’s advisory identifies these affected Spring Framework ranges:

• 5.3.0 through 5.3.17
• 5.2.19.RELEASE and earlier

The fixed versions listed by Spring are 5.3.18 and 5.2.20.RELEASE. Upgrade to the corresponding fixed release or a later release approved for your application, and check the current Spring or product-vendor advisory for the supported remediation path. Applications bundled in a commercial or vendor-managed product should follow that product’s security advisory and update instructions. [Spring affected versions and remediation]

How to assess exposure

1. Find every deployed application and artifact. Include services, older deployments, staging environments, and software delivered by another supplier.
2. Identify the Spring Framework version actually loaded. Inspect the dependency tree, lock or dependency-management files, packaged WAR/JAR contents, and runtime or software-composition inventory. A declared dependency may differ from the version bundled or loaded at runtime.
3. Record the deployment context. Determine the JDK version, whether the application uses Spring MVC or WebFlux, servlet container, and packaging (WAR or executable JAR). For the specific exploit scenario in Spring’s advisory, the requirements include JDK 9+, Tomcat, WAR packaging, and spring-webmvc or spring-webflux.
4. Check the owning vendor’s advisory. If Spring is inside a vendor product, ask the supplier whether the product uses Spring Core and whether its update addresses CVE-2022-22965. Apply the supplier’s product-specific patch when required.
5. Use scans as clues, not proof. NCSC-NL notes that scanner results do not guarantee the absence of vulnerable systems. Confirm findings against artifacts, runtime configuration, and vendor guidance. [NCSC-NL operational guidance]

Deployment factors to compare

Factor	Why it matters	What to verify
Spring Framework version	The advisory names affected and fixed ranges.	Loaded/bundled version, not only the version you intended to use.
JDK	The documented vulnerability is described for JDK 9 and later.	Runtime JDK for each deployed instance.
Web stack	The advisory concerns Spring MVC or Spring WebFlux applications.	Whether spring-webmvc or spring-webflux is present and used.
Container	The documented exploit scenario uses Apache Tomcat.	Servlet container and any product-specific changes.
Packaging	The described scenario requires WAR packaging.	WAR deployment versus executable JAR, including vendor wrappers.
Product ownership	Vendors may bundle or modify framework dependencies.	Supplier advisory, affected product versions, and supplied update.

Spring says a default Spring Boot executable JAR is not vulnerable to the specific exploit it describes. That statement is limited to that exploit scenario; the advisory also warns that other exploit paths may exist. Do not generalize it into a claim that all executable-JAR or Spring Boot deployments are safe. [Spring advisory]

How to fix Spring4Shell

1. Upgrade Spring Framework. For the affected 5.3 line, Spring lists 5.3.18 as fixed; for the 5.2 line, it lists 5.2.20.RELEASE. Prefer a currently supported release compatible with your application and follow the vendor’s instructions.
2. Update vendor-managed software through its vendor. Do not replace libraries inside a packaged product unless the supplier directs you to do so. Confirm the product version and remediation in its own advisory.
3. Rebuild and redeploy all affected instances. Ensure the fixed dependency is in the deployed artifact and loaded by the running process. Update replicas, scheduled jobs, and secondary environments too.
4. Verify the result. Recheck the packaged and runtime dependency versions and confirm that each instance is on the intended fixed version.
5. Investigate possible compromise independently. Patching closes the known vulnerability path; it does not show whether an attacker used it before remediation.

Spring’s advisory says no other steps are necessary after upgrading to the listed fixed versions. If you cannot upgrade immediately, follow the mitigation steps linked from the advisory and treat them as temporary risk reduction, not a substitute for the fixed release. [Spring upgrade and mitigation guidance]

Check for signs of compromise

Review logs and systems for the period the application may have been vulnerable, including systems already patched. NCSC-NL specifically advises checking logs on both vulnerable and patched systems. Microsoft documents detection and hunting options for its own Defender products and discusses firewall and WAF detections; these controls are product-specific and do not replace remediation. A non-malicious request test described by Microsoft can indicate susceptibility to the published proof of concept, but it is not a comprehensive security test. [NCSC-NL guidance] [Microsoft guidance]

• Preserve relevant application, Tomcat, access, error, and security logs before normal retention removes them.
• Look for unexpected JSP files or other newly written web-accessible files, unusual access-log configuration changes, and unexpected application behavior. The documented proof of concept involved writing a JSP web shell through Tomcat access-log settings; this is an investigation lead, not an exhaustive indicator list.
• Correlate suspicious requests or file changes with deployment, administrative, and host activity around the same time.
• If there is evidence of unauthorized access, use your incident-response process to assess affected credentials, systems, and data. Preserve evidence and involve the appropriate security team or incident-response support.

There is no universal log query or single probe that establishes compromise status across all application configurations. Assess evidence in the context of the actual server, product, and logging setup.

Common errors and how to resolve them

Problem	Likely cause	What to do
A dependency file shows a fixed version, but the scanner still reports an affected one.	An older transitive dependency, packaged artifact, or running instance remains.	Inspect the final WAR/JAR and runtime classpath; rebuild and redeploy every affected instance.
A scan finds no vulnerable Spring version, but exposure is still uncertain.	Scanners can miss embedded or vendor-managed components.	Check supplier advisories and inventory packaged/runtime dependencies; do not use a clean scan as proof.
The application is an executable JAR, so the team closes the issue.	The specific Spring statement about default executable JARs is being generalized.	Document why the known exploit prerequisites do or do not apply, then assess the vendor’s full guidance and any other exploit paths.
Only the primary production server was updated.	Replicas, jobs, staging, or older deployments were missed.	Reconcile the deployment inventory and verify each running instance and artifact.
Logs are clean after the patch, so no incident review is done.	Remediation and retrospective compromise checks have been conflated.	Review the vulnerable period as well as post-patch logs; logs may be incomplete, so consider host and product evidence too.
A vendor product contains Spring, but the framework version is unclear.	The framework is embedded or managed by the supplier.	Ask the supplier whether Spring Core is used, which product versions are affected, and which vendor update remediates the issue.
A temporary mitigation is treated as the permanent fix.	Upgrade constraints have delayed a fixed release.	Track the mitigation as temporary and plan the vendor-supported upgrade as soon as possible.

Performance, reliability, and cost considerations

For this issue, the primary operational cost is the engineering and service-disruption risk of updating and validating deployed applications. Plan a staged rollout appropriate to your environment, verify application behavior after the dependency change, and account for every instance and vendor product. The sources cited here do not provide a universal performance impact, downtime estimate, or cost figure for remediation; these depend on the application and deployment.

For reliable remediation, maintain an inventory of deployed artifacts and owners, record the fixed version in the change, and verify what is running rather than relying solely on a source manifest. For reliable investigation, preserve logs and correlate application and host evidence. Use vendor advisories for current product-specific status.

Or skip the browser setup

For a separate task—capturing a page for documentation or incident records—ScreenshotNeo is a website screenshot API and MCP server. A screenshot can document what a page visibly displayed, but it does not detect Spring4Shell, establish exposure, or replace server-side log review.

One GET request returns an image or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000.

Sign up for 1,000 free screenshots a month, no card required.

Frequently asked questions

Is Spring4Shell the same as Log4Shell?

No. Spring4Shell is the common name for CVE-2022-22965 in Spring Framework. Log4Shell refers to a different vulnerability in Log4j.

Does a CVSS score of 9.8 mean my application is compromised?

No. The score describes the vulnerability’s severity under the NVD rating; it does not determine whether your deployment meets exploit prerequisites or whether it was attacked.

Can a vulnerability scanner confirm that every system is safe?

No. NCSC-NL cautions that scan results do not guarantee the absence of vulnerable systems. Validate software inventories, deployed artifacts, runtime details, and supplier advisories.

Where can I find the authoritative fix for a bundled product?

Use the product supplier’s security advisory and remediation instructions, alongside Spring’s framework advisory.