Cve-2021-44228 log4j 2 exploit

Community Community Feedback
1

Hello everyone,

I think now this is all over internet that log4j 2.0 - 2.14.x had a bug which was causing RCE(Remote Code Execution) and is exploited.
We are using very sensitive data with the Camunda platform on premises and on cloud. We are using Camunda Platform 7.16.0 inside kubernetes.
We would like to know if camunda in any case is affected by this exploit because I think on the camunda’s github license book I saw camunda is using log4j 2.14? Correct me if I’m wrong please.
If Camunda is affected is there any update already out, or is an update already planned?

Many thanks in advance

1 Like
2

As far as I could investigate, camunda does not heavily rely on log4j and I could only see the dependency explicitly used in wildfly distro POM.

If you are hosting any other hosted mode of distribution just validate again by checking if the jar exists in classpath

1 Like
3

Hi @shan-96 thanks for you reply.

I saw here Camunda Platform License Book | docs.camunda.org the the log4j-api 2.14.x is being used

4

Hi @farhadnowzari, hi @shan-96,

thanks for your input regarding this.

To our current assessment, the Camunda Platform distributions (like WildFly, Tomcat, and Run) do not contain the vulnerable Log4J Core artifact by default. Some distributions contain the Log4J API or Log4J-to-SLF4J bridge, but those are not vulnerable on their own without the Log4J Core artifact (see also [1] and [2]).

Unless you added the Log4J Core artifact in any way, you should not be vulnerable to the attacks described in CVE-2021-44228.

Nonetheless, Camunda will update to Log4J versions >=2.15.0 as soon as possible.

Hope that helps,
Tobias

7 Likes