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!
In order for a vulnerability to be a risk to you, several things need to come together:
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. Or the other way round, as long as you 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 even with leaving the library sitting in your environment. But as said, having the library is the mandatory first element of the chain. So while that is present, it is possible that somebody writes code tomorrow that gets you to "2" and "3"!
Thus, 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.
In my bigcorp environment, orders were pretty simple: don't waste any time analysing whether your code uses the corresponding interfaces. When your projects contain the vulnerable JAR, upgrade it immediately. Period.