Currently a vulnerability in the Log4j logging framework has happened. But in our project we are not using log4j dependency directly. We are using log4j via org.apache.common. So the question is will it be affected or not?
Currently a vulnerability in the Log4j logging framework has happened. But in our project we are not using log4j dependency directly. We are using log4j via org.apache.common. So the question is will it be affected or not?
When using Apache Commons Logging, you still have to provide a specific logging system for Apache Commons Logging to use. If that specific system happens to be Log4j (either provided explicitly or implicitly because it's the primary default of Apache Commons Logging), you should assume that your project is affected by the vulnerability and update your log4j dependency to a patched version or use a different logging system.
Check if the classpath contains class JndiLookup or not. As suggested from this article
Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior.
You can find out transitive dependencies by using
gradle -q dependencyInsight --dependency org.apache.logging.log4j-core --configuration scm
and if you figure out that in the dependency tree path you have the vulnerable version present, then you need to take action.
More information :- Detecting Apache Log4j vulnerability presence in gradle transitive dependencies