banning-log4j2.pom.xml

<!-- plug-in configuration to put into your parent POM for avoiding any usages of
     outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
     latest version of log4j2 at
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

and for gradle users I was lucky to pass by this
https://twitter.com/CedricChampeau/status/1469608906196410368?t=6kUAHJBJMgrvPI5KLgLy2g&s=19

try against all repos listed here: https://github.com/apache/log4j/network/dependents

Any chance anyone has come across a version of this for sbt (scala build tool)?

Reminder that if you are adding this to a pom that already inherits from a parent POM you likely want something like:

          <bannedDependencies>
            <excludes combine.children="append">
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>

This will ensure that the definition in your POM doesn't overwrite the one inherited from parent and instead appends to it.

Thx for the snippet.
You might want to update your snippet to exclude 2.15.0 as well, as according to https://www.lunasec.io/docs/blog/log4j-zero-day/ (update from yesterday) the 2.15.0 version has still a limited vulnerability

Good point indeed, @mebe1012. Updated the gist accordingly, and took the liberty to update @hashhar's comment as well.

Sorry, pardon for my ignorance. Should the patch be added to the build -> plugins path or to the build -> pluginManagement -> plugins path? I have included in both points (alternatively) and I still see in the dependencies a log4j-1.2.15.jar file: Is that ok? It's an indirect dependency I don't see how to take away. We normally use logback-classic-1.2.1.jar should we update the dependency?

@mojadita, put it to build/plugins. That you see log4j-1.2.15.jar despite having this rule in place is expected, as this is a different group id and artifact id (and log4j 1.x is not affected by the RCE CVE). You still may want to consider to upgrade either to the latest log4j 2.x or to move to an alternative such as Logback, as log4j 1.x hasn't been actively maintained for several years now and has other (albeit less critical) known CVEs.

With the plugin added along with to project pom file, build fails if it finds any banned versions (even with transitive dependency of vulnerable log42 version) and wondering if there is way to avoid the build failure but rely on valid log4 versions provided by the project pom file. Not sure if this even is a good case :)

@gunnarmorling
Thank you for the snippet.
You might want to update your snippet to exclude 2.16.0 as well ? Apache has released 2.17.0 , as new CVE is disclosed overnight by Apache CVE-2021-45105,Fixed in Log4j 2.17.0

Updated to 2.17.0.

@gunnarmorling I can only get this to work if I use brackets instead of parenthesis, i.e.

<exclude>org.apache.logging.log4j:log4j-core:[,2.16.0]</exclude>

instead of

<exclude>org.apache.logging.log4j:log4j-core:(,2.16.0)</exclude>

The documentation at https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html also seems to indicate that without being completely explicit

You might want to update your snippet to exclude 2.17.0 as well ? Apache has released 2.17.1 , as new CVE is disclosed by Apache CVE-2021-44832,Fixed in Log4j 2.17.1
https://logging.apache.org/log4j/2.x/security.html

Adding to what @vegegoku reference posted:

Here is a link which might be helpful for Gradle projects
https://blog.gradle.org/log4j-vulnerability