I found the recent blog post on avoiding the log4shell vulnerabilities (CVE-2021-44228 and so on) by forcing minimum dependency versions, at https://blog.gradle.org/log4j-vulnerability. However, that may not help you in some situations, e.g., if
- you can’t upgrade yet for some reason;
- you need to rebuild older, vulnerable versions of a project; or
- you may be building source you don’t control, and you’re not sure if it has been upgraded (or, indeed, accidentally downgraded by the Spring Boot Gradle plugin, as in https://discuss.gradle.org/t/why-this-dependency-constraints-dont-work/41647/2.
In that case, you might want to apply the hook which a colleague and I put together, shared at https://github.com/HughG/gradle-cache-log4shell-patch. This adds a
DependencyResolutionListener which watches for any version of the
log4j-core JAR and deletes known problematic files from it within your Gradle cache. This ensure that no unit test runs, applications, WARs etc. from your project will contain those files in the copy of the
log4j-core JAR they use. The JAR should stay patched unless and until it is removed from your Gradle cache.
This has only really been tested with Gradle 6.2.2 and 6.8.1, on Windows 7 and Windows 10, but ought to work with any JDK version from (1.)7 onwards, any Gradle version from 3.4 onwards, and on any platform.
You can add it to your project’s build.gradle and I think that will apply to
buildSrc and build script dependencies as well. Alternatively you can add it to an
init.d folder in your Gradle user home directory and it will apply to all Gradle builds on your machine.