log4j exploit – is it still vulnerable if log4j is maintained in classpath but not actually used in code?

This is regarding vulnerability reported with CVE-2021-44228 against the log4j-core jar and has been fixed in Log4J v2.15.0.

We use Logback API via slf4j. This is confirmed with below code.

final StaticLoggerBinder binder = StaticLoggerBinder.getSingleton();
System.out.println(binder.getLoggerFactory());
System.out.println(binder.getLoggerFactoryClassStr());
//output:
//ch.qos.logback.classic.LoggerContext[default]
//ch.qos.logback.classic.util.ContextSelectorStaticBinder

mvn dependency:tree shows log4j-core API (version <2.15) in classpath (both direct & transitive dependency).

Is the application still vulnerable due to maintaining log4j-core in classpath? Thank you!

>Solution :

In order for a vulnerability to be a risk to you, several things need to come together:

1. the corresponding library exists in your environment
2. the corresponding library calls do happen in your environment at runtime
3. 3rd party users figure a way to get their (unchecked) input to that library call

Nobody here can tell you whether "2." and ".3" are applicable in your environment.

But: when you eliminate 1., you know that "2." and "3." are no longer possible. So, when you are 100% convinced that there is no path how a user can enter data into your system that makes it to the corresponding API, then you should be fine, too.

Nonetheless, keep in mind the perspective of higher management: most likely, the business decision might be: reduce the risk to 0, so make sure you don’t even have the corresponding JAR sitting on your machines.