In our blog you will find many exciting articles about i‑effect®, EDI and IBM i. If you have suggestions for a topic that interests you, we look forward to your suggestions.

Note about i‑effect® and the Log4j vulnerability (CVE-2021-44228)

Abstract - The gap in the Log4j software component is currently being reported by many sides. i‑effect® is not affected by the security vulnerability CVE-2021-44228 in Log4j 2.x. In older versions of i‑effect®, however, version 1.2 of Log4j was used in the ZUGFeRD module. Even though this version is not affected by CVE-2021-44228, we recommend users of i‑effect® 2.7.62 (only the ZUGFeRD module) to update to the latest i‑effect® version due to another less critical vulnerability in Log4j 1.2 (CVE-2021-4104).

Thursday, 16. December 2021

Is i‑effect® affected by the Log4j vulnerability?

No, the standard software components of i‑effect® are not affected by the current Log4j vulnerability (CVE-2021-44228) after examining the source code and the changelog of the latest versions.

Log4j is no longer used in our software in current versions, i‑effect® uses a different logging framework (SLF4j + Logback) for logging.

Furthermore, also not affected by the security vulnerability:

  • the "Apache Tomcat" server used in i‑effect® in conjunction with module *WEBCONTRL
  • the files "log4j-over-slf4j.jar", "log4j-to-slf4j.jar" and "log4j-api.jar".

Log4j 1.x in older version of i‑effect® (i-effect 2.7.62 in connection *ZUGFERD)

In older versions of i‑effect® and in a few versions within version 2.7, version Log4j 1.2 was used for a short time by the ZUGFeRD module. The versions 1.x of LOG4j, however, are not affected by the current vulnerability CVE-2021-44228, because these do not include lookups.

For version 1.2, there is another vulnerability (CVE-2021-4104) where an attacker could perform a similar attack in combination with a setting by changing the Log4 configuration. According to the BSI, exploitation is only possible in combination with a malicious program configuration and is therefore rather unlikely.

“The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.”

In perspective, users with i‑effect® version 2.7.62 and the *ZUGFERD module to update the ZUGFeRD obsolete version of LOG4j 1.2 should upgrade to a current i‑effect® version.

What you should check anyway!

Affected could be active users of the *SOA module or other individual developments. Please come in this case for the purpose of further review in any case to us.

Even if your i‑effect® version is >= 2.8, there might still be directories and files of previous versions like 2.6, 2.7 etc. in the IFS. If there is the affected Log4j file/version "log4j-core-*.jar" in it, it has no effect, because these files are not used by the newer i‑effect® versions. You can delete these JAR files without any problems.


Back to overview
Contact form
Contact form

Got any more questions? Tell us more about your project and we will get back to you as soon as possible.

I have read and understood the privacy policy. I agree that my contact details and information for queries will be stored permanently. Submit

How can we help? Chat with us! One of our experts will be here for your right away!

I have read and understood the privacy policy. I agree that my contact details and information for queries will be stored permanently. Start chat