Note: The fix is needed on installs prior to edgeCore 4.3.10-hotfix2.

Below are the steps you need to take to apply the fix:

• Open the environment.bat/.sh file and in :: — Other runtime preferences, add the following:
  log4j2.formatMsgNoLookups
• If using a Windows-based server add this to environment.bat:
  set CUSTOM_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true
• If using a Linux-based server add this to environment.sh:
  CUSTOM_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true
• Restart edgeCore. Once the system is back up:
  – Go to the system menu > Admin Tools > System Config;
  – In Scope, select SYSTEM and filter by log;
  – You should see the following:
  

Update: December 15
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath.
Example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

This needs to be run on:
zip -q -d ./tomcat/bin/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
zip -q -d ./tomcat/webapps/ROOT/WEB-INF/lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Alternatively, you can contact the Support team to obtain the 4.3.10-hotfix3, where this additional vulnerability has been resolved.

Update: December 20

This page previously mentioned other mitigation measures, but those measures only limit exposure while leaving some attack vectors open.

Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf(“%s”, userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors. The safest thing to do is to upgrade Log4j to a safe version or remove the JndiLookup class from the log4j-core jar.

Apache Log4j version 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0.
Contact the Support team to obtain the 4.3.10-hotfix4 that contains the upgraded Log4j. Additionally, the following patches are also available: edgeCore-3.8.5, edgeCore-3.11.4, and edgeCore-4.3.8.