We take the notification of the German Federal Office for Information Security (BSI) dated 11.12.2021 regarding the announcement “Critical vulnerability in log4j published (CVE-2021-44228)” as an opportunity to inform you regarding our solutions.

A rated critical vulnerability in the widely used Java library Log4j allows attackers to execute arbitrary code. Since the vulnerability can be exploited without explicitly reloading malicious code, the German Federal Office for Information Security (BSI) subsequently upgraded the zero-day vulnerability to the highest warning level, red, last weekend.


i-doit relies entirely on PHP and does not use Java at all. There, even after scans on our i-doit instances,
no log4j files.


Version of OTRS, Znuny LTS or Znuny uses log4j by default.
Only OTOBO installations using Elasticsearch could be affected.

In the OTOBO application network, only Elasticsearch uses Log4Shell and could therefore potentially be affected. https://otobo.de/de/otobo-und-cve-2021-44228/

According to current statements from Elasticsearch, OTOBO is basically not affected by the major security threats (remote code execution, data leaks). The key sentence here is: “Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage.”

In German: “Supported Elasticsearch versions (6.8.9 and newer, 7.8 and newer) deployed with current JDK versions (JDK9 and newer) are not at risk from remote code execution or data leaks.” (to Elasticsearch’s statement)

OTOBO has been using JDK 16, Elasticsearch since the first beta in version 7.14+. In manually set up instances using Elasticsearch with OpenJDK 8, limited .env data could probably be leaked.


JDisc uses log4j version 1.2.17 up to build 5091. This is also vulnerable, but only in the config when JMSAppender is used. This is not used by the manufacturer and the build has been adjusted to version 2.15.0. https://blog.jdisc.com/2020/12/03/lldp-med-improved-discovery/


The vulnerability, which could allow an attacker to execute arbitrary code by sending crafted log messages, has been identified as CVE-2021-44228 and is named Log4Shell. According to https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot OpenCelium users are not affected by this vulnerability.
not affected
because we use the default logging system instead of log4j.

However, if you want to update dependencies for log4j, you need to follow the next instruction:

Open build.gradle file and put implementation


in dependencies.


We will be happy to support you with any update measures.

Kind regards,
the team of becon GmbH

Subscribe to our blog!

We’re not just going to talk about us here,
but above all provide interesting information about the change of IT with all its technological facets.


Related blog articles

becon takes over the software DATAGERRY from NETHINKS

becon takes over the software DATAGERRY from NETHINKS

After successful negotiations, the acquisition of the DATAGERRY software developed by NETHINKS has now been officially confirmed. Managing partner of becon GmbH Mr. Steffen Rieger and managing director Mr. Uwe Bergmann of NETHINKS GmbH agreed on the takeover.


Instant contact

Do you have any questions, suggestions, requests or are you facing a particular challenge? We look forward to hearing from you!

+49 (0) 89 608668-0