It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Application Firewall

Spring Framework: Critical Vulnerability Spring4Shell

  • Last updated on

This article provides updates on recently discovered vulnerabilities (CVE-2022-22963 and CVE-2022-22965) in Spring Framework.

The following table provides key information about the vulnerabilities.

CVE NumberCommonly Known/Associated AsCriticality &  CVSS ScoreExploit TypeSoftware Firmware VersionsPrerequisite to Exploit VulnerabilityBarracuda WAF Affected


Relates to old CVE-2010-1622

Zero-dayRCESpring MVC and Spring WebFlux applications running on JDK 9+ Application running on Tomcat as WAF deployment NO
CVE-2022-22963 SpEL (Spring Expression Language)CriticalELV->RCE Spring Cloud Function versions : 3.1.6, 3.2.2 and older unsupported versions NO

Spring Framework is an application framework and inversion of control container for the Java platform. Recently, two vulnerabilities were discovered in Spring Framework (CVE-2022-22965) and in Spring Cloud Function (CVE-2022-22963).

Spring4Shell is a misnomer for all these vulnerabilities combined (CVE-2022-22965, CVE-2022-22950 & CVE-2022-22963). Spring4Shell refers to CVE-2022-22965. Also, note that Spring4Shell has no relation with the log4shell vulnerability.

The following sections list the difference between these vulnerabilities, along with their effects and mitigation.



CVE-2022-22963 was reported on March 29, 2022. It affects Spring Cloud functions only, which is not in Spring Framework. Spring has already released a newer version to take care of this. CVE-2022-22963 uses routing functionality to provide specially crafted Spring Expression Language (SpEL) as a routing expression to access local resources and perform RCE. It uses a specific HTTP request header:

Barracuda WAF is not affected by this vulnerability. 


This is an RCE, and a malicious actor can provide a specially crafted SpEL as a routing expression that may result in access to local resources.


  • On the Barracuda WAF, you can manually perform the configuration changes mentioned under Barracuda WAF Manual Mitigation Configuration to protect against this vulnerability
Barracuda WAF Manual Mitigation Configuration

Enable “OS Command Injection” and “OS Command Injection Strict” patterns on the Security Policies > Parameter Protection page.

Additional Configuration Steps
  • Create a header ACL with the header name of and ensure the os-command-injection-medium and os-command-injection-strict are associated with this header ACL for inspection.
This may result in some false positives, depending on how the application names other parameters. The administrator can create the pattern initially in passive mode and evaluate the Web Firewall Logs generated. 

You can update your infrastructure as follows:



This vulnerability affects Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to run on Tomcat as a WAR deployment and will not work if the Spring Boot executable is in jar deployment. So by default, the deployed application is not vulnerable to this exploit.

Barracuda WAF is not affected by this vulnerability.


This is an RCE vulnerability, in Spring Core version 5.3.17 or earlier (for 5.3.x) and version 5.2.19 or earlier (for 5.2.x). It appears to be a bypass of protections set up for CVE-2010-1622.

  • On the Barracuda WAF, you can manually perform the following configuration changes to protect against this vulnerability.
Configuration Steps
  • As a very strict approach, it is advised to create a pattern ((\x2e)?Class(\x2e)+)|((\x2e)+Class(\x2e)?) and use this pattern to validate the parameter name. Set Case Sensitivity to No.


    Then, bind it to the Custom Blocked Attack Types on the Parameter Protection page.
    For this to work, you must scroll down to the Validate Parameter Name setting and select Yes.


  • As a general recommendation, we suggest to keep os-command-injection-medium and strict patterns enabled while keeping an eye on possible false positives.

This may result in false positives, depending on how the application names other parameters. Administrators can configure the pattern initially in passive mode and evaluate the Web Firewall Logs generated.

Vendor advisory:

  • Spring Framework 5.3.18 and 5.2.20, which contain the fixes, have been released.
  • Spring Boot 2.6.6 and 2.5.12 that depend on Spring Framework 5.3.18 have been released.
  • Apache Tomcat has released versions 10.0.20, 9.0.62, and 8.5.78, which close the attack vector on Tomcat’s side. See Spring Framework RCE, Mitigation Alternative.
Further Reading: