Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added LOG4J_FORMAT_MSG_NO_LOOKUPS=true

...

  • Upgrading log4j2 to 2.15.0 (or better)
    • This is the best fix
  • Use system property log4j2.formatMsgNoLookups=true to disable message formatting
    • This is a reasonable workaround
    • Setting a shell environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true should work too
  • Remove the following files from your jar file: log4j-core-2.XX.Y.jar  (This is a hack. A simple one but effective)
    • org/apache/logging/log4j/core/net/JndiManager$1.class
    • org/apache/logging/log4j/core/util/JndiCloser.class
    • org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class
    • org/apache/logging/log4j/core/lookup/JndiLookup.class
    • org/apache/logging/log4j/core/net/JndiManager.class
    • org/apache/logging/log4j/core/selector/JndiContextSelector.class
  • Ensuring your JRE is 1.8.121 or better. (This version doesn't fix the issue, it just eliminates one very easy to exploit attack vector.)
    • But these 2 system properties must also be set to false (or unset) com.sun.jndi.rmi.object.trustURLCodebase,com.sun.jndi.cosnaming.object.trustURLCodebase
    • Newer JVM's can still fall victim to this attack with the older log4j2. It is beyond the scope of this FAQ to explain how. But the TL;DR is it the exploit becomes more application or application server specific.

...