Skip to main content

Log4j vulnerability in Kofax FraudOne

Article # 3037042 - Page views: 389


CVE-2021-44228 was discovered on 2021-12-10, the question remains if FraudOne modules are affected by this critical security vulnerability.
More details about the vulnerability can be found on the Apache website:



The Apache Log4j2 RCE vulnerability allows to execute remote code via Log4j's JNDI API which ranked as a critical vulnerability.



FraudOne does not use Log4j library directly.

The included log4cxx library (C++ port of log4j) cannot be used to perform LDAP lookups for log strings.

There is only one dependency in our ThinClient called esapi-2.0.1.jar (OWASP Enterprise Security API) that transitively references log4j:1.2.16 only when configured in (SignPlus.war\WEB-INF\classes\):
# Log4JFactory Requires log4j.xml or in classpath -
ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory -> default value

However, this setting is not enabled by FraudOne by default. Moreover, Log4j 1.x does not offer a lookup mechanism, it does not suffer from CVE-2021-44228)!


In addition, Professional Service found no references to Log4j 2.x library in customizations for customers.



General possible mitigations include:

  • Upgrade Apache Log4j to version 2.15.0 or higher.
  • Block the possibility of JNDI to communicate with non-trusted servers.
  • For releases >=2.10 the configuration value log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS can be set to true.
  • For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
  • For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Level of Complexity 



Applies to  

Product Version Build Environment Hardware
FraudOne All All Java n/a




  • Was this article helpful?