New vulnerabilities in Spring libraries: how to know if you are at risk and what to do
Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). To help make it easier for you to understand if you are at risk for either vulnerability and what actions to take, we’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function.”
Vulnerability 1 - “Spring4Shell” (CVE-2022-22965)
On March 29th, 2022, the community discovered a series of tweets containing screenshots of a proof of concept of an exploit targeting Spring Core (SC) , which allows for Remote Code Execution for all versions of Spring Core, including the most recently released version, 5.3.17.
What applications are at risk?
Currently, only applications being hosted on Tomcat are confirmed to be at risk to this new exploit. While the exploitation has not been demonstrated as successful against the Embedded Tomcat Servlet Container, or any other non-Tomcat hosted applications, that does not rule out the possibility of the threat proving successful in the future to these frameworks.
Spring released an official statement about the vulnerability, which clarifies that the following conditions need to be met to be vulnerable, according to the current understanding of the vulnerability:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
How does the “Spring4Shell” exploitation work?
The exploitation relies on using “Data Binding” (org.springframework.web.bind.WebDataBinder) in requests that make use of Plain Old Java Objects (POJO) in the method signature:

Where the Foo class is a POJO class, which could be defined as the following. Note that the actual class isn’t important, as long as it’s loaded by the Class Loader.

When a request is handled by a method like this, the Class Loader is used to resolve the class. The Class Loader is responsible for loading classes at runtime, without having to preload all possible types into memory first. It figures out which .jar file to load when a new class is used.
You can find the most up to date and in-depth information about this vulnerability directly from Spring on their blogpost, including potential fixes or workarounds.
Vulnerability 2 - Spring Cloud Function (CVE-2022-22963)
On March 27th 2022, Cyber Kendra disclosed details about a 0-day Remote Code Execution (RCE) vulnerability in Spring Cloud Functions for which no patch existed. The vulnerability was assigned the ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.
What applications are at risk?
The vulnerability affected applications under these conditions:
- JDK 9 or newer
- Spring Cloud Functions version 3.1.6 (or lower), 3.2.2 (or lower), or any unsupported version
How does the exploitation work?
Spring Cloud Function provides the capability for developers to configure how routing is handled through the property spring.cloud.function.routing-expression, usually done through configuration, or code. This is a powerful capability that accepts the “Spring Expression Language” (SpEL). Through this 0-day vulnerability, we have learned that this property could be set through the HTTP headers of a request, which meant that an attacker could embed SpEL code directly in their HTTP request to a RoutingFunction endpoint, and thus execute arbitrary code.
What steps should users take to mitigate risk?
Spring has released versions 3.1.7 and 3.2.3 to address this issue by not allowing this property to be set through HTTP headers, mitigating the vulnerability. After upgrading to either version, no additional steps are necessary.
Interested in learning more about how we help developers write more secure code? Book a demo or explore our free secure coding guidelines on secure code coach.
Sources
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/


Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). We’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function” to help you understand if you're at risk and what to do if you are.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo

Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). To help make it easier for you to understand if you are at risk for either vulnerability and what actions to take, we’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function.”
Vulnerability 1 - “Spring4Shell” (CVE-2022-22965)
On March 29th, 2022, the community discovered a series of tweets containing screenshots of a proof of concept of an exploit targeting Spring Core (SC) , which allows for Remote Code Execution for all versions of Spring Core, including the most recently released version, 5.3.17.
What applications are at risk?
Currently, only applications being hosted on Tomcat are confirmed to be at risk to this new exploit. While the exploitation has not been demonstrated as successful against the Embedded Tomcat Servlet Container, or any other non-Tomcat hosted applications, that does not rule out the possibility of the threat proving successful in the future to these frameworks.
Spring released an official statement about the vulnerability, which clarifies that the following conditions need to be met to be vulnerable, according to the current understanding of the vulnerability:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
How does the “Spring4Shell” exploitation work?
The exploitation relies on using “Data Binding” (org.springframework.web.bind.WebDataBinder) in requests that make use of Plain Old Java Objects (POJO) in the method signature:

Where the Foo class is a POJO class, which could be defined as the following. Note that the actual class isn’t important, as long as it’s loaded by the Class Loader.

When a request is handled by a method like this, the Class Loader is used to resolve the class. The Class Loader is responsible for loading classes at runtime, without having to preload all possible types into memory first. It figures out which .jar file to load when a new class is used.
You can find the most up to date and in-depth information about this vulnerability directly from Spring on their blogpost, including potential fixes or workarounds.
Vulnerability 2 - Spring Cloud Function (CVE-2022-22963)
On March 27th 2022, Cyber Kendra disclosed details about a 0-day Remote Code Execution (RCE) vulnerability in Spring Cloud Functions for which no patch existed. The vulnerability was assigned the ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.
What applications are at risk?
The vulnerability affected applications under these conditions:
- JDK 9 or newer
- Spring Cloud Functions version 3.1.6 (or lower), 3.2.2 (or lower), or any unsupported version
How does the exploitation work?
Spring Cloud Function provides the capability for developers to configure how routing is handled through the property spring.cloud.function.routing-expression, usually done through configuration, or code. This is a powerful capability that accepts the “Spring Expression Language” (SpEL). Through this 0-day vulnerability, we have learned that this property could be set through the HTTP headers of a request, which meant that an attacker could embed SpEL code directly in their HTTP request to a RoutingFunction endpoint, and thus execute arbitrary code.
What steps should users take to mitigate risk?
Spring has released versions 3.1.7 and 3.2.3 to address this issue by not allowing this property to be set through HTTP headers, mitigating the vulnerability. After upgrading to either version, no additional steps are necessary.
Interested in learning more about how we help developers write more secure code? Book a demo or explore our free secure coding guidelines on secure code coach.
Sources
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). To help make it easier for you to understand if you are at risk for either vulnerability and what actions to take, we’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function.”
Vulnerability 1 - “Spring4Shell” (CVE-2022-22965)
On March 29th, 2022, the community discovered a series of tweets containing screenshots of a proof of concept of an exploit targeting Spring Core (SC) , which allows for Remote Code Execution for all versions of Spring Core, including the most recently released version, 5.3.17.
What applications are at risk?
Currently, only applications being hosted on Tomcat are confirmed to be at risk to this new exploit. While the exploitation has not been demonstrated as successful against the Embedded Tomcat Servlet Container, or any other non-Tomcat hosted applications, that does not rule out the possibility of the threat proving successful in the future to these frameworks.
Spring released an official statement about the vulnerability, which clarifies that the following conditions need to be met to be vulnerable, according to the current understanding of the vulnerability:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
How does the “Spring4Shell” exploitation work?
The exploitation relies on using “Data Binding” (org.springframework.web.bind.WebDataBinder) in requests that make use of Plain Old Java Objects (POJO) in the method signature:

Where the Foo class is a POJO class, which could be defined as the following. Note that the actual class isn’t important, as long as it’s loaded by the Class Loader.

When a request is handled by a method like this, the Class Loader is used to resolve the class. The Class Loader is responsible for loading classes at runtime, without having to preload all possible types into memory first. It figures out which .jar file to load when a new class is used.
You can find the most up to date and in-depth information about this vulnerability directly from Spring on their blogpost, including potential fixes or workarounds.
Vulnerability 2 - Spring Cloud Function (CVE-2022-22963)
On March 27th 2022, Cyber Kendra disclosed details about a 0-day Remote Code Execution (RCE) vulnerability in Spring Cloud Functions for which no patch existed. The vulnerability was assigned the ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.
What applications are at risk?
The vulnerability affected applications under these conditions:
- JDK 9 or newer
- Spring Cloud Functions version 3.1.6 (or lower), 3.2.2 (or lower), or any unsupported version
How does the exploitation work?
Spring Cloud Function provides the capability for developers to configure how routing is handled through the property spring.cloud.function.routing-expression, usually done through configuration, or code. This is a powerful capability that accepts the “Spring Expression Language” (SpEL). Through this 0-day vulnerability, we have learned that this property could be set through the HTTP headers of a request, which meant that an attacker could embed SpEL code directly in their HTTP request to a RoutingFunction endpoint, and thus execute arbitrary code.
What steps should users take to mitigate risk?
Spring has released versions 3.1.7 and 3.2.3 to address this issue by not allowing this property to be set through HTTP headers, mitigating the vulnerability. After upgrading to either version, no additional steps are necessary.
Interested in learning more about how we help developers write more secure code? Book a demo or explore our free secure coding guidelines on secure code coach.
Sources
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoRecently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). To help make it easier for you to understand if you are at risk for either vulnerability and what actions to take, we’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function.”
Vulnerability 1 - “Spring4Shell” (CVE-2022-22965)
On March 29th, 2022, the community discovered a series of tweets containing screenshots of a proof of concept of an exploit targeting Spring Core (SC) , which allows for Remote Code Execution for all versions of Spring Core, including the most recently released version, 5.3.17.
What applications are at risk?
Currently, only applications being hosted on Tomcat are confirmed to be at risk to this new exploit. While the exploitation has not been demonstrated as successful against the Embedded Tomcat Servlet Container, or any other non-Tomcat hosted applications, that does not rule out the possibility of the threat proving successful in the future to these frameworks.
Spring released an official statement about the vulnerability, which clarifies that the following conditions need to be met to be vulnerable, according to the current understanding of the vulnerability:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
How does the “Spring4Shell” exploitation work?
The exploitation relies on using “Data Binding” (org.springframework.web.bind.WebDataBinder) in requests that make use of Plain Old Java Objects (POJO) in the method signature:

Where the Foo class is a POJO class, which could be defined as the following. Note that the actual class isn’t important, as long as it’s loaded by the Class Loader.

When a request is handled by a method like this, the Class Loader is used to resolve the class. The Class Loader is responsible for loading classes at runtime, without having to preload all possible types into memory first. It figures out which .jar file to load when a new class is used.
You can find the most up to date and in-depth information about this vulnerability directly from Spring on their blogpost, including potential fixes or workarounds.
Vulnerability 2 - Spring Cloud Function (CVE-2022-22963)
On March 27th 2022, Cyber Kendra disclosed details about a 0-day Remote Code Execution (RCE) vulnerability in Spring Cloud Functions for which no patch existed. The vulnerability was assigned the ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.
What applications are at risk?
The vulnerability affected applications under these conditions:
- JDK 9 or newer
- Spring Cloud Functions version 3.1.6 (or lower), 3.2.2 (or lower), or any unsupported version
How does the exploitation work?
Spring Cloud Function provides the capability for developers to configure how routing is handled through the property spring.cloud.function.routing-expression, usually done through configuration, or code. This is a powerful capability that accepts the “Spring Expression Language” (SpEL). Through this 0-day vulnerability, we have learned that this property could be set through the HTTP headers of a request, which meant that an attacker could embed SpEL code directly in their HTTP request to a RoutingFunction endpoint, and thus execute arbitrary code.
What steps should users take to mitigate risk?
Spring has released versions 3.1.7 and 3.2.3 to address this issue by not allowing this property to be set through HTTP headers, mitigating the vulnerability. After upgrading to either version, no additional steps are necessary.
Interested in learning more about how we help developers write more secure code? Book a demo or explore our free secure coding guidelines on secure code coach.
Sources
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Table of contents

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Professional Services - Accelerate with expertise
Secure Code Warrior’s Program Strategy Services (PSS) team helps you build, enhance, and optimize your secure coding program. Whether you're starting fresh or refining your approach, our experts provide tailored guidance.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.