Is WildFly affected by the log4j 2 vulnerability CVE-2021-44228?

Question

We are using wildfly 10 and 16 in production and a zero-day exploit exists CVE-2021-44228 for log4j for some versions.

How can I be sure that none of the code and libraries use a log4j lib that has that issue?

I do not use any log4j property file nor do I add a dependency by myself.

Any help would be greatly appreciated!

Vehement

Answer 1

The affected log4j versions are:

Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1

WildFly uses log4j shaded via its log4j-jboss-logmanager module. Even the latest 1.2.2.Final version depends on log4j 1.2.17.

This means WildFly <22 is definitely not affected.

There is a log4j2-jboss-logmanager as well - but only WildFly 22+ has it. And as this doc explains:

This will be an implementation of the log4j2 API only. The core log manager for log4j2 will not be supported.
Usage of any org.apache.logging.log4j:log4j-core API’s or implementations will not be supported. In other words the log4j2 log manager implementation, including configuration files, will not be supported.

You can see that the current latest 1.0.0.Final release does not depend on log4j-core at all, only log4j-api.

So WildFly versions >=22 are not affected as well.

The official tweet confirms this.

But what about WFCORE-5743 raising the log4j-core version? Look in the pom:

<!-- This is a test only dependency -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>${version.org.apache.logging.log4j}</version>
    <scope>test</scope>
</dependency>

It's not bundled with WildFly, only used in WildFly's build for tests.

Witt

As a follow up there was also a blog post addressing this wildfly.org/news/2021/12/13/Log4j-CVEs. – Purify

Vsevolod made a good analysis. To sum it up: If your application does not use log4j itself or tries to configure it, you can say that it is safe when it runs on WildFly. WildFly itself only supplies log4j-api (log4j-api-2.17.1.jar or similar), which only contains the interfaces/definitions, not the vulnerable code. – Tarboosh

Answer 2

Fixed in WildFly Core 18.0.0, to be included in WildFly 26.0.0.Final:

https://issues.redhat.com/browse/WFCORE-5743

https://issues.redhat.com/browse/WFLY-15807

If you need to use WildFly 10 or 16 in production, you should use JBoss EAP instead:

https://access.redhat.com/articles/112673#EAP_7

Slogan

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Atheling

This tweet says that WildFly is not affected, although I'd like a statement on Wildfly's site instead of a social media. twitter.com/WildFlyAS/status/1469362190536818688< So, the situation is a bit confusing. – Counterfoil