Since many software vendors have not yet released an update to their software, the question now is what can you do against this security vulnerability? There are a few patch options that can limit the impact until updates come out for these products. Here, updating to the latest version is always preferred, but if this is not immediately possible there are still the following ways:
UPGRADE TO LOG4J 2.17.0
In this, the problem is solved
LOG4J 2.10.0 – 2.14.2
Set System Property log4j2.formatMsgNoLookups to true
Environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS set to true
LOG4J 2.0-BETA9 – 2.10.0
org/apache/logging/log4j/core/lookup/JndiLookup.class remove the classpath. This is possible with this handy one-liner:
Setting the log4j2.formatMsgNoLookups property is also advised as a temporary mitigation by the NCSC . In addition, updating to Java JDK 6u211, 7u201, 8u191, and 11.0.1 or higher (>=12) may also partially help, but this does not protect in all cases . Indeed, when updating to the latest JDK version, the com.sun.jndi.ldap.object.trustURLCodebase property is set to false by default, but it is still possible in some cases to get remote code execution via Log4j. By the way, Log4j version 1 does not contain this particular security vulnerability, but there other security vulnerabilities are known, and also advised to update.
The preference is still to update, the mitigations are a temporary solution. For Java applications being developed in-house, it is recommended to upgrade to Log4j version >= 2.17.0 as soon as possible.