CSR Vulnerability

Last updated
Save as PDF

Vulnerability Name	Module	Is CSR Vulnerable?	Description	Fixed Version
CVE-2021-4104	Log4j	Not vulnerable	Wildfly internally uses 1.2.17 but org.jboss.logmanager:log4j-jboss-logmanager artifact that wildfly ships will shade the Log4j 1 classes, including JMSAppender. However if there is an attempt to configure JMSAppender it will fail, since org.jboss.logmanager:log4j-jboss-logmanager does not include a dependency on the module that provides the javax.naming package. Refence: https://www.wildfly.org/news/2021/12/13/Log4j-CVEs/ CSR uses log4j2 version 2.17.0 and this overrides the default log4j used by wildfly.	NA
CVE-2021-44228	Log4j 2	Not vulnerable	This vulnerability is in code in the Log4j 2 org.apache.logging.log4j:log4j-core artifact. The WildFly application server project does not ship this artifact, and it never has. So, the only way an application running on WildFly would be vulnerable to the CVE-2021-44228 vulnerability is if the log4j-core artifact has been added to the server installation, either via a user-provided JBoss Modules module, or more likely by packaging log4j-core in an application deployment artifact. Note that since WildFly 22, WildFly does ship the Log4j 2 org.apache.logging.log4j:log4j-api artifact, and up to WildFly 26.0.0.Beta1 the version of that artifact matches the CVE-2021-44228 CPE. However, the log4j-api artifact does not contain the vulnerable code. Note that even though the artifact on WildFly 26.0.0.Beta1 does not have the vulnerability, to help avoid confusion the upcoming 26.0.0.Final release will move to the 2.15.0 version of the artifact, which does not match the CVE-2021-44228 CPE. We are using 25.0.1 final wildfly. As we are in 2.17.0 we are safe.

Vulnerability Name

Module

Is CSR Vulnerable?

Description

Fixed Version

CVE-2021-4104

Log4j

Not vulnerable

Wildfly internally uses 1.2.17 but org.jboss.logmanager:log4j-jboss-logmanager artifact that wildfly ships will shade the Log4j 1 classes, including JMSAppender.

However if there is an attempt to configure JMSAppender it will fail, since org.jboss.logmanager:log4j-jboss-logmanager does not include a dependency on the module that provides the javax.naming package.

Refence: https://www.wildfly.org/news/2021/12/13/Log4j-CVEs/

CSR uses log4j2 version 2.17.0 and this overrides the default log4j used by wildfly.

CVE-2021-44228

Log4j 2

Not vulnerable

This vulnerability is in code in the Log4j 2 org.apache.logging.log4j:log4j-core artifact. The WildFly application server project does not ship this artifact, and it never has. So, the only way an application running on WildFly would be vulnerable to the CVE-2021-44228 vulnerability is if the log4j-core artifact has been added to the server installation, either via a user-provided JBoss Modules module, or more likely by packaging log4j-core in an application deployment artifact.

Note that since WildFly 22, WildFly does ship the Log4j 2 org.apache.logging.log4j:log4j-api artifact, and up to WildFly 26.0.0.Beta1 the version of that artifact matches the CVE-2021-44228 CPE. However, the log4j-api artifact does not contain the vulnerable code. Note that even though the artifact on WildFly 26.0.0.Beta1 does not have the vulnerability, to help avoid confusion the upcoming 26.0.0.Final release will move to the 2.15.0 version of the artifact, which does not match the CVE-2021-44228 CPE.

We are using 25.0.1 final wildfly. As we are in 2.17.0 we are safe.