Unpatched Java Spring Framework 0-Day RCE Bug Threatens Enterprise Web Apps Security

A zero-day remote code execution (RCE) vulnerability has come to
light in the Spring framework shortly after a Chinese security
researcher briefly leaked^[1]
a proof-of-concept^[2]
(PoC) exploit^[3]
on GitHub before deleting their account.

According to cybersecurity firm Praetorian, the unpatched flaw
impacts Spring Core on Java Development Kit (JDK^[4]) versions 9 and later
and is a bypass for another vulnerability tracked as CVE-2010-1622^[5], enabling an
unauthenticated attacker to execute arbitrary code on the target
system.

Spring is a software framework^[6]
for building Java applications, including web apps on top of the
Java EE (Enterprise Edition) platform.

“In certain configurations, exploitation of this issue is
straightforward, as it only requires an attacker to send a crafted
HTTP request to a vulnerable system,” researchers Anthony Weems and
Dallas Kaman said^[7]. “However, exploitation
of different configurations will require the attacker to do
additional research to find payloads that will be effective.”

Additional details of the flaw, dubbed
“SpringShell” and “Spring4Shell,”
have been withheld to prevent exploitation attempts and until a fix
is in place by the framework’s maintainers, Spring.io, a subsidiary
of VMware. It’s also yet to be assigned a Common Vulnerabilities
and Exposures (CVE) identifier.

It’s worth noting that the flaw targeted by the zero-day exploit
is different from two previous vulnerabilities disclosed in the
application framework this week, including the Spring Framework
expression DoS vulnerability (CVE-2022-22950^[8]) and the Spring Cloud
expression resource access vulnerability (CVE-2022-22963^[9]).

In the interim, the company is recommending “creating a
ControllerAdvice component (which is a Spring component shared
across Controllers) and adding dangerous patterns to the
denylist.”

Initial analysis of the new code execution flaw in Spring Core
suggests that its impact may not be severe. “[C]urrent information
suggests in order to exploit the vulnerability, attackers will have
to locate and identify web app instances that actually use the
DeserializationUtils, something already known by developers to be
dangerous,” Flashpoint said^[10] in an independent
analysis.

Despite the public availability of PoC exploits, “it’s currently
unclear which real-world applications use the vulnerable
functionality,” Rapid7 explained^[11]. “Configuration and JRE
version may also be significant factors in exploitability and the
likelihood of widespread exploitation.”

The Retail and Hospitality Information Sharing and Analysis
Center (ISAC) also issued a statement^[12] that it has
investigated and confirmed the “validity” of the PoC for the RCE
flaw, adding it’s “continuing tests to confirm the validity of the
PoC.”

“The Spring4Shell exploit in the wild appears to work against
the stock ‘Handling Form Submission’ sample code from spring.io,”
CERT/CC vulnerability analyst Will Dormann said^[13] in a tweet. “If the
sample code is vulnerable, then I suspect there are indeed
real-world apps out there that are vulnerable to RCE.”