The Recent Log4j2 Vulnerability and How to Address it in Spring Boot Applications

By now, you probably will have heard about the Log4Shell 0-day exploit in Log4j 2 already.

Since this is relevant to every Java developer and potentially every Java and hence – by extension – every Spring Boot application out there, I’d like to address this issue and how to mitigate it in Spring Boot applications.

When using the default settings without any other dependencies, Spring Boot applications in general won’t be vulnerable because Spring Boot uses Logback in its starter dependencies.

However, if your application uses Log4j 2, for example, because you switched from the default logging framework, you can fix this vulnerability by setting the log4j2.version property to Log4j 2 version 2.15.0, which contains a fix for this security issue.

Moreover, if your project uses dependencies other than Spring Boot ones, those might transitively load a vulnerable Log4j 2 version without you necessarily being aware of it.

In either of those cases, it’s advisable to check if a vulnerable Log4j 2 version has been loaded into your application and update that dependency, if necessary.

In case your project uses Maven, you can set the Log4j 2 version by adding this to your project’s pom.xml:

This is the equivalent statement for Gradle’s build.gradle:

The new Spring Boot version 2.6.2, which is due on December 23, 2021, will come with version 2.15.0 of Log4j 2 by default. You can find more information about these fixes in this article on the official Spring Blog.