Spring Fixes Zero-Day Vulnerability in Framework and Spring Boot

The exploit requires a specific nonstandard configuration to work, limiting the danger it poses, but future research could turn up more broadly usable attacks.

The Spring development team today acknowledged the newly reported SpringShell, also called Spring4Shell, vulnerability, releasing new versions of the Spring Framework and Spring Boot to fix the root cause of the issue in the popular Java frameworks.
The vulnerability — issued the Common Vulnerabilities and Exposures (CVE) identifier CVE-2022-22965 — affects applications that use Spring MVC, a framework implementing the model-view-controller architecture for Web applications, and Spring WebFlux, if they run on version 9.0 or higher of the Java Development Kit, according to an advisory the Spring developers issued.
The current exploit for the issue, however, is somewhat limited, as it requires that the application is deployed as a specific type of file — a Web Archive (WAR) file — on Apache Tomcat, rather than the standard deployment method of a Spring Boot executable in the Java Archive (JAR) format.
However, as more security researchers examine the code and search for additional paths through which to exploit the vulnerability, that could change, Spring committer Rossen Stoyanchev warned in the advisory./p>
The nature of the vulnerability is more general, and there may be other ways to exploit it, he said.
Time to Patch Spring Apps
Companies should prioritize patching all of their Spring Framework- and Spring Boot-based applications, even if they do not run the specific, known-vulnerable configurations, security experts say. Development teams often do not know their full software bill-of-materials (SBOM), which could leave them unaware of potentially vulnerable configurations.
In addition, these sorts of vulnerabilities tend to mutate over time as researchers look for other avenues of exploitation, says Ilkka Turunen, field CTO at software management and security firm Sonatype.
What is very typical in a situation like this — just look back three months at Log4j — there is a ton of attention being cast on the issue, both good and bad, researchers thinking about the exploitable classes, he says. However, that quickly evolves. In Log4j we found four other CVEs come out related to the original issue, and we expect that to happen here.
The Spring developers first learned of the vulnerability on Tuesday, March 29, but the details of the issues leaked out before the development team had finished the patch and disclosure, Springs Stoyanchev
stated in the Spring advisory
.
On Wednesday we worked through investigation, analysis, identifying a fix, testing, while aiming for emergency releases on Thursday, he said. In the mean time, also on Wednesday, details were leaked in full detail online, which is why we are providing this update ahead of the releases and the CVE report.
Figuring out whether a companys Spring-based applications are vulnerable will be difficult for most companies, as this is a particularly tricky vulnerability, Edward Wu, senior principal data scientist for ExtraHop, a cloud cybersecurity firm, said in a statement sent to Dark Reading.
Most teams have hundreds of vendor-provided software in their environments that may or may not be running Spring Core, he says. They often don’t have access to the source code and will struggle to determine if they’re vulnerable. It will be important for organizations to be able to query their environment but also track activity within their network as a single source of truth.
Not the Next Log4j
Overall, however, the vulnerability in Spring falls short of the Log4Shell exploit for the critical vulnerability in Log4j, even though some companies have placed the two issues on the same level, Dan Murphy, distinguished architect at application security provider Invicti, said in a statement.
Spring4Shell, as some companies have named the vulnerability, relies on a configuration that is not the default for modern Spring applications, he said. If a company runs their Spring Boot apps as a standalone application, then they are likely not vulnerable.
While the Spring4Shell vulnerability is serious and absolutely needs patching, our initial findings indicate it wont be the next Log4Shell incident, Murphy said. That said, organizations should still follow standard best practices and make a plan to patch. The underlying issue is still present and could potentially be exploited in as-yet-undiscovered ways.
On Wednesday, several security researchers had confused the new exploit with information circulating around a second vulnerability that had been disclosed the prior day. The vulnerability,
CVE-2022-22963
, affects the Spring Cloud Function library, but also had been assigned the wrong severity. The Spring development team upgraded that vulnerabilitys severity to Critical on March 31.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Spring Fixes Zero-Day Vulnerability in Framework and Spring Boot