Tags: security, cve



A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. This announcement was followed by additional vulnerabilities discovered and logged as CVE-2021-45046 and CVE-2021-45105. The vulnerabilities impact Apache Log4j 2 versions 2.0 to 2.14.1, 2.15.0, 2.16.0.

This article summarizes the currently known potential impacts to Kublr products and related announcements for mitigations of the issue.

Kublr Components Potentially Affected by the Vulnerability

Only  Java-based components can be affected by the vulnerability as Log4j2 is a java library.

Kublr includes the following Java-based components:

  1. Keycloak
  2. Elasticsearch with Search Guard plugin
  3. Logstash


Keycloak is not affected by the vulnerability according to Keycloak developers due to the fact that Keycloak does not include Log4j2 core implementation jar, it only includes Log4j2 API classes.

Elasticsearch with Search Guard Plugin

According to Elasticsearch developers, while Elasticsearch components may contain the affected libraries, the currently 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. This is due to Elasticsearch’s usage of the Java Security Manager.

According to Search Guard developers, Search Guard solely depends on the Log4j2 component shipped by Elasticsearch.

Recent versions of Kublr (1.20.0+) use Elasticsearch 7.9.0 and 7.10.2 with JDK 11+ and therefore are not susceptible to the issue.


According to Elasticsearch developers, exposure to remote code execution exists on JDKs prior to 8u191. On newer versions of JDKs there is exposure to Denial of Service and information leakage, but no known remote code execution exposure. Logstash has no known vulnerabilities to CVE-2021-45105.

Recent versions of Kublr (1.20.0+) use Elasticsearch 7.9.0 and 7.10.2 with JDK 11+ and therefore are not susceptible to the issue.


As described in the previous sections, the vulnerability is low severity in the context of Kublr as it cannot be exploited due to the way Log4j2 library is used in Elasticsearch. Nevertheless it is possible to use one of the following mitigation strategies.

1. Upgrade Elasticsearch components to 7.16.2

This strategy can be used with Kublr versions 1.20.0+. Elasticsearch upgraded Log4j2 library version in 7.16.2 release.

The downside of this approach is that starting from the release 7.11 Elasticsearch uses the Server Side Public License (SSPL) and ELv2 instead of Apache 2.0 and EL licenses. The use of the basic Elasticsearch version (the one included in Kublr by default) is still free but the new license model applies additional limitations, in particular, the Elasticserach products cannot be provided to the end users as managed service.

You may find more information about the license model change in the Elasticsearch documentation: https://www.elastic.co/pricing/faq/licensing

To upgrade the Elasticsearch version used in Kublr, make the following changes in the cluster specification of the control plane and of the clusters that use standalone logging:

            registry: cr.kublr.com
            name: kublr/logstash
            tag: 7.16.2-1
              tag: 7.16.2-1
              tag: 7.16.2-1
              tag: 7.16.2-1

2. Disable Kublr Logging

Log collection and deployment of logging components can be disabled with the following changes in the cluster specifications:

        enabled: false