Find and Fix Springshell

Last updated: Monday, April 4, 2022, at 12:18 pm EST

This is an ongoing situation. This page and the Sonatype blog post will be continuously updated with the latest information.

News broke on March 30, 2022, of a new vulnerability, dubbed "Springshell / Spring4shell" in the community, as a new, previously unknown security vulnerability.

Sonatype deep-dive data research has confirmed that this serious vulnerability affects the spring-beans and spring artifacts under the following conditions:

  • JDK >=9 is being used.
  • The application is deployed as a .war (as opposed to a Spring Boot executable jar)

Anyone using software built on Spring—a large population of enterprise Java software—is possibly affected. This vulnerability has been added to Sonatype data as SONATYPE-2022-1764 and given the designation CVE-2022-22965 with a CVSS Score of 9.8.

The SONATYPE-2022-1764 issue is a duplicate of CVE-2022-22965, as Sonatype reported this issue before a CVE ID was officially released.

Spring has released patched versions 5.3.18 and 5.2.20 as well as remediated versions of Spring Boot—available on Maven Central. We recommend an immediate upgrade

Select a Nexus Solution

Nexus Lifecycle (find and fix the Springshell vulnerability across applications)

Nexus Firewall (find if Springshell exists in your repository and prevent future downloads of vulnerable versions of Springshell)

Nexus Repository (find if Springshell exists in your repository)

Nexus Lifecycle

The following information helps Nexus Lifecycle users find and fix Springshell vulnerabilities.

How do I know if my applications are affected by the Springshell vulnerability (CVE-2022-22965)?

Your Dashboard results will show the most recent violations. The Dashboard is displayed by default when you log into Lifecycle. You can also access it by clicking the Dashboard icon on the left navbar:

Click the Filter button to adjust your results. For example, you can filter by security threat severity. Large organizations with lots of scanned apps should set the Age filter to Past 7 Days or Past 24 hours to reduce potential slowdowns.

Click Apply in the Filter menu to view your results:

Click the Export Violations Data button to save a CSV of the results:


If you scanned your application before the vulnerability was known, (and/or previously encountered issues), you can manually search applications for this vulnerability using the following REST endpoint to find the impacted spring-beans versions. This can be entered in a browser (without leading/trailing quotes) if logged into your IQ server or used programmatically (see the nexus-iq-api-scripts repo on the Sonatype Community Github). 

NOTE: Update the following with your IQ Server address, password, and target stage (e.g., stageId=release ).

http://localhost:8070/api/v2/search/component?stageId=release&componentIdentifier=%7B%22format%22%3A%22maven%22%2C%22coordinates%22%3A%7B%22groupId%22%3A%22org.springframework%22%2C%22artifactId%22%3A%22spring-beans%22%2C%22version%22%3A%22*%22%2C%22extension%22%3A%22*%22%2C%22classifier%22%3A%22*%22%7D%7D%E2%80%9D

An example REST API call to the Nexus IQ server follows. Please note that the REST endpoint in the Sonatype blog post is equivalent to those below, but the encoding works for Windows, macOS, and Linux.

curl -u admin:password -X GET "http://localhost:8070/api/v2/search/component?stageId=release&componentIdentifier=%7B%22format%22%3A%22maven%22%2C%22coordinates%22%3A%7B%22groupId%22%3A%22org.springframework%22%2C%22artifactId%22%3A%22spring-beans%22%2C%22version%22%3A%22*%22%2C%22extension%22%3A%22*%22%2C%22classifier%22%3A%22*%22%7D%7D%E2%80%9D"

Alternatively, the Advanced Search feature is available in Nexus Lifecycle. A search term you can use is: componentCoordinateArtifactId:spring-beans

Because Sonatype identified this vulnerability before it was assigned a CVE, Nexus Lifecycle calls this vulnerability sonatype-2022-1764. If using the Advanced Search feature, use this identifier instead of CVE-2022-22965.

The best practice for identifying Springshell components in your application is to run a full, new scan. Avoid using re-evaluate in this situation. Clicking the Re-evaluate Report button on an existing report only reapplies policies to the scan data, and the vulnerabilities do not change.

You will need to onboard your application to Lifecycle. Please see our Approaches to onboarding applications guide for help.

You can then run a scan via the CLI to get results.

The following example shows the command line for an Application ID Test123, a URL of http://localhost:8070 , and targets the release stage. Replace <version> in the jar file path with your version of the CLI.

java -jar ./nexus-iq-cli-<version>.jar -i Test123 -s http://localhost:8070 -a username:password -t release sample-application.zip


Springshell is in my application. How do I fix it?

We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The best option is to upgrade Springshell to a newly released, non-vulnerable version immediately.

Spring has released patched versions 5.3.18 and 5.2.20 available on Maven Central. We recommend an immediate upgrade.

We strongly recommend upgrading to a non-vulnerable version of Springshell. If that is not possible, Spring has suggested workarounds.

Reference: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement#suggested-workarounds


How do I protect my applications going forward?

The best practice is to turn on the Continuous Monitoring feature. Continuous Monitoring lets you use existing policies with notifications to constantly watch (once a day, based on your configuration) for new violations at a specific development stage (such as Release). Configure Continuous Monitoring in two steps: (1.) turn it on for an application or organization, and then (2.) turn it on at the policy level and set your notifications.

To turn on Continuous Monitoring for an application or organization:

  1. Select Organization & Policies icon from the left navigation bar:
  2. Select the organization or application whose policies you want to monitor.
  3. Under Continuous Monitoring, click the chevron next to Inherit from Root Organization (Do not monitor).
  4. In the Continuous Monitoring view, click the desired stage.
  5. Click Update to turn on Continuous Monitoring.

The next step is turning on Continuous Monitoring at the policy level. This lets you identify who should receive an email message when a violation of the current policy occurs.

To turn on Continuous Monitoring in a policy:

  1. In the Organization & Policy area, create a new policy or open an existing one for an organization or application.
  2. In the Policy editor, click the Notifications button to scroll to the Notifications section.
  3. Make sure the Notifications Recipient list contains the desired email address to use for policy violation notifications. If necessary, add a new recipient.
  4. For the desired email address, click Continuous Monitoring to select it.
  5. Click Update to save the policy.

For more information, please see our Notifications and Monitoring guide.

Nexus Lifecycle can be configured to send email notifications for events such as policy violation notifications. Email is a simple way to start getting notifications to the application security team, and eventually developers once they have been notified to expect them. 

This functionality requires an SMTP server, which is configured along with a number of other options in the Mail Configuration section of the config.yml file.

Email notifications from the IQ Server are automatically sent to recipients when a policy alert occurs. The email contains information about the application and violation and provides a link to the full results for further investigation.

For more information, please see our Notification Configuration help topic.


Nexus Firewall

The following information helps Nexus Firewall users identify if Springshell exists in your repository and prevent future downloads of vulnerable versions of Springshell.


Nexus Firewall can audit component downloads from a given proxy repository (Java, .NET, npm, Python). You can view a report that contains all components that have been previously downloaded to your Nexus Repository through that applicable proxy repository.

This report can be reviewed for any instances of Springshell, and you can search for a particular Springshell component. In addition, the Firewall results include Sonatype-curated vulnerability information—for this CVE and others—only available to Sonatype Firewall and Lifecycle customers.

If this component is found, it indicates it was previously downloaded into your Nexus Repository. As a result, the component is available to applications with privileges to access that proxy repository. To associate a component to a specific application, please visit Sonatype’s Nexus Vulnerability Scanner (NVS) a no-cost scan tool. If you have numerous applications to analyze, we recommend reaching out to Sonatype Sales to trial the Nexus Lifecycle solution.

First, we recommend deleting vulnerable versions of this component from your proxy repos. Firewall's quarantine feature can block vulnerable versions from being reintroduced into your proxy repos. Set you security policies for severities 9 and 10 to Fail at the Proxy stage.

Spring has released patched versions 5.3.18 and 5.2.20 available on Maven Central. We recommend an immediate upgrade.

 Nexus Firewall will not block the spring-beans component if it is already in your repository unless you first delete the component.

In addition to auditing component downloads, Nexus Firewall is designed to quarantine component download requests based on policy configuration. You can configure the policy to quarantine new component downloads for known vulnerable versions of any component based on any range of criticality.


Nexus Repository

The following information helps Nexus Repository users identify if Springshell exists in your repository.


How do I determine if my organization is impacted by the latest vulnerability disclosure?

Repository Health Check (RHC) can audit component downloads from a given proxy repository. Users can view a report that contains all components, which have been previously downloaded to your Nexus Repository through that applicable proxy repository.

This report can be reviewed for any instances of Springshell. Users can also search for a particular Springshell component. In addition, the RHC report includes links to the associated CVE.

If this component is found, it indicates it was previously downloaded into your Nexus Repository. As a result, the component is available to applications with privileges to access that proxy repository. To associate a component to a specific application, please visit Sonatype’s Nexus Vulnerability Scanner (NVS) a no-cost scan tool. If you have numerous applications to analyze, we recommend reaching out to Sonatype Sales to trial the Nexus Lifecycle solution.

How should we remediate this issue?

First, we recommend deleting vulnerable versions of this component from your proxy repositories. If you're also a Firewall customer, review the information above to learn how Nexus Firewall can automatically quarantine vulnerable versions of this component.

If you do not have a means of blocking components from being reintroduced to your proxy repositories, you'll need to manually alert development teams to the danger.

Spring has released patched versions 5.3.18 and 5.2.20 available on Maven Central. We recommend an immediate upgrade.

How can Repository Health Check (RHC) help with other known vulnerabilities?

Enabling RHC on all supported repository types provides insight into component downloads across your proxy repositories. In addition, the report includes trend analysis determined by month-to-month component downloads.

Are Sonatype products vulnerable?

Sonatype conducted an audit of our applications, and we determined Sonatype products are not affected by the Spring4shell vulnerability.

Resources