Recently, the most popular open source lightweight Java framework Spring was exposed to a high-risk RCE (Remote Control Equipment) zero-day vulnerability , Peking University Computing Center, praetorian, bleepingcomputer and other sites have reported on the vulnerability.

According to a wildly popular online introduction, the RCE vulnerability stems from the SerializationUtils#dserialize method at the core of the Spring framework, which is based on Java’s serialization and deserialization mechanism and can lead to Remote Code Execution (RCE), which can potentially affect anyone using JDK9 and above.

Urgent fixes underway?

Looking at the Spring project’s Git commit log, it appears that Spring developers are urgently working on code related to the vulnerability while news of the vulnerability is spreading like wildfire, such as a new commit on March 29: deprecate SerializationUtils#deserialize.

At this sensitive point in time, the commit has caused some tension, with many users leaving comments below the commit asking if the code changes in the commit are related to the rumored 0day RCE vulnerability? One of the core Spring developers sbrannen clarified this:

Deprecating SerializationUtils#deserialize has nothing to do with all the current vulnerabilities.

The purpose of this commit is to inform users who have used SerializationUtils#deserialize that deserializing objects from untrusted sources is dangerous.

The Spring Core Framework does not use SerializationUtils to deserialize objects from untrusted sources.

In fact, a discussion of the SerializationUtils method appeared in the Spring Framework repository back on February 19, when developer ledoyen pointed out that, based on Java’s serialization mechanism, the SerializationUtils#dserialize could lead to an RCE remote code execution vulnerability, so he proposed a PR #28075 for deprecating SerializationUtils#dserialize.

pr 28075

So it seems that the previous commit was a code merge by ledoyen for this PR, and the deprecation of SerializationUtils#dserialize was planned. When asked under this PR whether SerializationUtils#dserialize should be reported as a vulnerability, ledoyen also explained:

SerializationUtils#dserialize is not inherently vulnerable, and using this tool to process user input data may lead to a CVE, but the method does not lead to any vulnerability when used internally as a CacheResultInterceptor.

Currently, SerializationUtils#dserialize is deprecated in Spring Framework 6.0, and for version 5.3.x, a warning against the SerializationUtils utility class is added to Javadoc to raise user awareness.

Vulnerability hype

If it does exist, then this Spring framework RCE vulnerability would have far more impact than Log4j or Heartbleed before it, but I’ve been digging around all day and haven’t seen anyone actually reproduce it (no full Poc, no vulnerability details).

There are a lot of new repositories on GitHub named Spring core RCE, but they are basically “you should know” riddle descriptions with no real value.

Spring framework RCE vulnerabilit

As of press time, the Spring team has not issued any official bulletins about this vulnerability: the latest vulnerability bulletins on the official blog are CVE-2022-22963: Spring Expression Resource Access Vulnerability and CVE-2022-22950: Spring Expression DoS Vulnerability, but both are of moderate severity and cannot be compared to the webcast Spring Core Framework’s RCE criticality.