Is there a Log4j2 vulnerability with Spring Boot?

Your thoughts?


Yes. If you use the Log4J framework with Spring Boot then you are vulnerable.

Spring Boot uses logback implementation by default. This is often replaced with Log4J and other alternatives.

Log4j features include substitutions and lookups to generate dynamic log entries. For example, if you want to log the version of Java you are using you can use ${java:runtime} to lookup the actual runtime being used.

This sounds flexible and awesome but the problem comes with JNDI lookups. JNDI is an awkward Java protocol for accessing Java objects across different directory structures.

JNDI servers include malicious remote LDAP servers. Unfortunately for log4j, user input can be craftily entered to trigger JNDI lookups to remote (malicious) servers with no authentication.


What is the Log4J2 vulnerability?

The CVE-2021-44228 vulnerability is a remote code execution (RCE) vulnerability. It exists in the popular Apache Log4J library and poses a serious threat to any application exposing user input to the Log4J framework.

Does the Log4J2 vulnerability exist in Spring Boot?

Yes! While Spring Boot uses the logback framework by default, it is often configured to use an alternate logging implementation like Log4J2.

If you're Spring Boot app is configured to use the Log4J framework, then your application is vulnerable. Keep in mind that even if you don't directly import the log4j library directly in your project, other dependencies may rely on it as sub dependencies.

How can I remediate the Log4J2 vulnerability in Spring Boot?

You can upgrade the Apache log4J library to >= 2.15 or use another framework altogether. You can use the default logback implementation with Spring Boot or use other alternatives like java.util.logging etc.


yes but only if you are referencing user inputs in your logs....


Our story begins with the Apache Log4J library. Part of the popular Apache Logging project, Log4J makes it easy for Java developers to log errors in their application. This logging implementation is used by millions of Java based applications around the world. Some of the biggest companies in the world including Amazon and Red Hat leverage this logging framework.

So what's so dangerous about a logging framework? Well it turns out that Log4J utilizes a lookup() method to optionally rely on JNDI calls to retrieve remote user inputs. With a well crafted user input string, attackers can force this lookUp to pull and execute remote server code without any authentication or other security measures.

The issue is widespread and serious. RCE is a very serious problem.


Spring Boot by default uses logback. If you are logging through something like @Sl4j then you are using Spring Boot logging.