Security firms produced two data points on Monday to estimate the number of Spring Framework installations that are vulnerable to the most recent flaw — CVE-2022-22965, also known as Spring4Shell or SpringShell — suggesting anywhere from hundreds of thousands to millions of instances are affected.

Details of the vulnerability were leaked last week less than 24 hours after the issue was disclosed to the Spring project, leaving security professionals and developers scrambling. Scans for the specific combination of factors that suggest a vulnerable instance found 150,000 vulnerable devices after scanning a quarter of the Internet, suggest that as many as 600,000 devices may have the vulnerable component that could be exploited by the leaked code, says Jared Smith, senior director of threat intelligence at security metrics firm SecurityScorecard.

In addition, SecurityScorecard's honeypot servers have detected active attempts to exploit the issues, he says.

"Given early reports suggest [SpringShell affected] around 6,000 devices, this new number is much worse," Smith says. "Log4j was much harder to assess whether an exposed port was using a Java-based application with Log4j behind the scenes. This is much more visible and directly available to exploit and test."

Other security firms have released data that supports a similar magnitude of impact for SpringShell. On April 4, Sonatype released data showing that 81% of the applications built using the Spring Beans component as a dependency are using a potentially vulnerable version as of Monday. While the data only revealed the relative balance between updated and potentially vulnerable components, Sonatype stated that the issues is "affecting millions of users," on its SpringShell Exploit Resource Center page. The live dashboard tracks the number of potentially vulnerable downloads of the component.

The number of updated Spring Beans (green) compared with vulnerable versions (red). Source: Sonatype

Not the Same as Log4j
SpringShell is a critical issue, but it is not an "Internet-on-fire" issue like the Log4j vulnerability, and the patching rate shows, Ilkka Turunen, field CTO at software management and security firm Sonatype, wrote in a blog post on April 4.

"Even at this early stage, we can already see a slower rate of update adoption compared to Log4j," he wrote. "This is most likely due to the vulnerability only affecting some Spring users in specific configurations. This graph will help us understand the fixed adoption rate in the days and weeks ahead."

The lack of immediacy to patch the SpringShell vulnerability is because the current exploit code requires a specifically configured Spring application to be able to utilize the flaw. The application has to be installed on an Apache Tomcat server running JDK 9 or newer and packaged as a Web archive (WAR) file. In addition, the application has to use the Spring Beans package via the Spring WebMVC and Spring WebFlux component.

Those requirements significantly reduce the potential vulnerable instances, Sonatype's Turunen wrote on the company's blog.

"The reality ... is that due to the mitigating circumstances, only a small percentage of deployments are truly vulnerable to the issue," he wrote. "That said, with any big project, there is a ton of legacy out there that can result in older and unmaintained systems becoming potential entry points."

The sentiment was also echoed by software supply chain security firm JFrog, which confirmed that its platform is not affected by the issue. In its own analysis, the company broke down the issue, identifying the root cause of the problem: "{S]tarting from Java 9, due to an introduction of a new API, ... it is possible to bypass Spring’s protection and assign arbitrary values to properties of the ClassLoader attribute."

The company also stressed that, because the vulnerable configuration is not a default configuration, even Spring applications with the vulnerable component may not be vulnerable.

"While the SpringShell vulnerability is serious in its impact on Java applications, there are very specific circumstances that must exist for an organization to be at risk," Shachar Menashe, senior director of JFrog's security research, said in a statement sent to Dark Reading.

What to Do About the SpringShell Vuln
SecurityScorecard recommends that companies scan both their internal networks and conduct external scans for the vulnerable configuration. In addition, companies should should keep track of their software bill of materials to know when their application frameworks could be exposed to vulnerabilities, such as SpringShell and Log4j.

SecurityScorecard also stressed that developers and application security professionals should not be complacent because the vulnerability will likely not be exposed to the current vulnerability. Other exploits will surely follow, the company stated in an analysis.

"If this feels all-too-familiar and is reminding you of the Equifax hack that was due to an exploitation of the Apache Struts2 framework, then your instinct is spot on," the company stated. "This is the same kind of vulnerability."