This message was deleted.

Gradle itself does not use Log4j 2 and whatever project you have it should not include Gradle and thus is not subject to the vulnerability just because Gradle has Log4j 2 somewhere in its transitives references. Well, unless I understand something wrong in your description. 😉 Check out https://blog.gradle.org/log4j-vulnerability for more information.

Thank you for your reply! Whenever I run a gradle sync, these files are appearing on my workstation. user/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/ This means that at some point, the gradle is using the log4j 2.10, and a hacker can run the RCE on my machine at this time. When I run a gradle sync with gradle version 6.9.2 it shows the log4j non vulnerable version 2.17. Sorry for sending a picture instead of screenshot, my workstation is highly secure and can't run slack on it

This means that something depends on it in your project, that is why it shows up in the cache. That does not mean that it is being called, and it most certainly does not mean that someone can call it from within Gradle since the cache is not the classpath of Gradle.

My project is not using log4j at all, I ran a dependency report on it. This path in my workstation is the .gradle general folder, not the project related folder. Thank you for your reply

Just so that you have two voices: what @Fleshgrinder said

Gradle uses a global cache for all projects you build to speed everything up. Also, while your project might not include Log4j in its dependencies (and thus nothing shows up in the dependency report) does not mean that there are no Gradle plugins that depend on it.

If it lands in that cache, either your project or maybe some Gradle plugin you use uses it.

Thank yall for your reply! I'll double check if there is anything on my workstation that is using the log4j

If so you could at least use

dependencies

and

buildEnvironment

tasks to find where it comes from

Something I noticed, is that when I update my gradle to 6.9.2, log4j in that specific folder appears as 2.17, which is nice but affects the app stability

You mean that your build breaks, because Gradle cannot affect the stability of a running app, since it’s a build tool. My only response to this, which might sound harsh but is the only possible response given the “high security” + “human lives depend on it” context: Always upgrade, everything, all the time, everywhere. It’s the only way to ensure safety and security. (Check checksums, verify signatures, … also for Gradle plugins.) Not doing so in this context is, well, reckless. Again, I don’t want to be harsh, and sorry to be so frank, but this is how it is given the context. The Log4j you see might be from the Scala plugin, in case you use Scala. That’s the one explained in the Gradle blog post I shared.

Don't worry, I totally get where you are coming from, but it isn't up to me to decide that HAHA I guess my company doesn't want to invest months worth of salary to upgrade the gradle. And, when I mean stability, I mean updating all the dependencies, layouts and anything that's involved with updating a gradle

Jumping from 4.1 to 6.9.2 is definitely going to be cumbersome since you jump over 2 major upgrades. I’m not surprised. 😞 The thing is that you might not even be able to update whatever pulls the vulnerable Log4j version, since it’s probably a Gradle plugin and newer versions require a newer Gradle version. What you definitely can do is to force upgrade Log4j in all places. Gradle 4.1 is long ago for me, but something like the following in your

build.gradle

should do the trick:

buildscript {
  dependencies {
    classpath("org.apache.logging.log4j:log4j-core:2.17.2")
  }
}

configurations.all {
  project.dependencies.add(name, "org.apache.logging.log4j:log4j-core:2.17.2")
}

This basically adds Log4j core with the latest version everywhere and thus forces resolution to this version. This is brute force and most probably has unwanted side effects, but it should work. Newer Gradle versions have better APIs to do something like this, and maybe Gradle 4.1 had some of those already too, but, as I said, Gradle 4.1 is way back for me, so I don’t remember.

Urgh, why should he add log4j-core to everywhere even if it is not there already? At most add a constraint, or just use the recommendation from that blog entry.

I really don’t know what kind of APIs Gradle 4.1 had to offer, as I wrote above, the example code is going to lead to unwanted side effects. Maybe you remember 4.1 better and can provide a better code snippet.

thank you for your replies, I had no idea how that cache folder was generated with the log4j

Yes, a plugin could depend on Log4j.

so, it could be a plugin issue in the project gradle files right?

I already told you how to find out, you just ignored it. 😉

https://gradle-community.slack.com/archives/CAHSN3LDN/p1654622035642049?thread_ts=1654619821.903759&cid=CAHSN3LDN I got it! thank you 🙂

😊