Over the last few months, following the scramble that was Log4j, I have been asking folks I meet “what if another critical vulnerability was announced tomorrow? What would you do differently?” Well, last Wednesday, we got a reminder that new security vulnerabilities can and do appear.
Spring4Shell, a previously unannounced and badly named Remote Code Execution (RCE) flaw, began as a series of rumors, first through qq messages followed by rumours on the twitter-sphere. These then quickly cascaded into blogs that took partial information into canon.
From there, the situation has clarified – there was a RCE and its severity is listed as “Critical,” but with some important caveats, namely that it affects those:
- Running the application packaged as a WAR
- Within the Tomcat environment
- On JDK 9 or newer
- Needs to include spring-beans through a
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.
This configuration is fortunately non-standard, as most Spring apps are now Spring Boot (insert sigh of relief here). The name, by the way, has nothing to do with Log4shell – but it probably raised the attention for this particular issue to a new level.
But why did the collective developer sphere skip a beat when the rumours first began to circulate?
Spring is mega-popular framework
Spring ranks in the top 3 in developer popularity in Java Frameworks , according to several different reports over the years, and its embrace by the community is comparable to Log4j. Developers like how Spring helps them write more efficiently by providing them with pre-made templates and utilities.
This translates to a lot of potentially affected deployments, which at first glance may seem like easy pray. The reality however (Read more...)
