Apache Log4j 2 vulnerability CVE-2021-44228

A critical security vulnerability has been identified in the popular "Apache Log4j 2" library. This vulnerability is identified as CVE-2021-44228.

Log4j in Jenkins

The Jenkins security team has confirmed that Log4j is not used in Jenkins core. Jenkins plugins may be using Log4j. You can identify whether Log4j is included with any plugin by running the following Groovy script in the Script Console:


If this results in the following error, Log4j is not included in any installed and enabled plugin:

groovy.lang.MissingPropertyException: No such property: org for class: Script1

Otherwise, the script output will print one location where Log4j is found, which includes the plugin name in the path. That plugin should be disabled or uninstalled, followed by a Jenkins restart and another script execution until the "No such property" error appears.

Affected plugins and their mitigation status are listed in the Jenkins issue tracker. See this Jira query for components known to be affected.

Log4j in web application containers

If you are hosting your Jenkins in a separate web application container like Tomcat, Websphere, or Glassfish, check with the providers of those containers to assess if they are using a vulnerable version of Log4j.

When Jenkins runs from the Docker image, a native installer package (deb, rpm, msi), or is invoked with java -jar jenkins.war, it is not running inside a separate web application container. It is using the built-in Jetty web application container that is bundled inside Jenkins and does not include Log4j.

Log4j in Jenkins project infrastructure

The Jenkins infrastructure team is currently checking all Jenkins project infrastructure for the presence of vulnerable versions of the Log4j library. This work is ongoing. We may decide to disable some services temporarily out of an abundance of caution. You can see the status of services on the status page.

This is a companion discussion topic for the original entry at https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/

The security team has provided more details in the Jira ticket tracking fixes in the affected plugins. If you’d like to know more about the affected versions of Apache Log4j 2, see


1 Like

I’m using a version which is not the latest (2.235).
How can I know if it’s affected or not by this CVE?

Same instructions apply. Open the script console, paste in that groovy script, and confirm the output says “No such property”.

Jenkins 2.235.x is vulnerable to other issues. See the security advisories for more details

I am using Jenkins version 2.320 on Centos 8.3. I find the following file present on the system: /var/cache/jenkins/war/WEB-INF/lib/log4j-over-slf4j-1.7.32.jar

I have performed the Groovy check for plugins which yielded the negative result listed above.

Can you please explain the use of this file in the Jenkins core (given the statement above), and why it is/is not vulnerable to CVE-2021-44228.

og4j-over-slf4j is an adapter JAR that allows projects to migrate from log4j to slf4j (Log4j Bridge) :

SLF4J ship with a module called log4j-over-slf4j . It allows log4j users to migrate existing applications to SLF4J without changing a single line of code but simply by replacing the log4j.jar file with log4j-over-slf4j.jar , as described below.

The jar is (I can only guess) a holdover from when Jenkins used to use log4j and migrated to slf4j.

From http://slf4j.org/log4shell.html:

If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.

Which would mean you just need to ensure the actual log4j 2.x jar is not there.


Thank you. I have confirmed that there is no log4j on the system, neither 1.x nor 2.x.

# find / -type f -name "*log4j*"
# yum list installed | grep -i log4

You have multiple high and critical vulnerabilities. I would worry about those before I’d worry about log4j.

1 Like

I ran the: org.apache.logging.log4j.core.lookup.JndiLookup.class.protectionDomain.codeSource
Received: groovy.lang.MissingPropertyException: No such property: org for class: Script1
with a stack trace. Yet I have a vulnerable version of log4j located at:


I’m running 2.303.3.

Anyone have a clue why or how I can get rid of or upgrade this?


See the reply from @batmat in the Jenkins user mailing list.

That file location is a cache maintained by Apache Maven. If that is your Jenkins controller, it likely means that you’re making the mistake of building on the Jenkins controller. Don’t do that. Reasons why are described in

Can someone please confirm how to check if Jenkins is affected by similar less critical vulnerability CVE-2021-4104 ?

The National Vulnerability Database says

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration (emphasis added). … Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default

Jenkins core makes no mention of JMSAppender. I believe it is not configured to use JMSAppender.

If you’re granting write access to the Jenkins Log4j configuration on your Jenkins controller, I believe that means you have granted write access to the Jenkins home directory. If you’ve given someone write access to the Jenkins home directory, they are assumed to be trusted.

Note, I’m not part of the security team, so my assessment may be incorrect, but as far as I can tell, Jenkins is not vulnerable to that issue.

We have log4j vulnerabilities in our Jenkins instance. Our plugins looks fine. Nonetheless, the following appears in our scan:

The version of Apache Log4j on the remote host is 2.x < 2.15.0. It is, therefore, affected by a remote code execution vulnerability in the JDNI parser due to improper log validation. An unauthenticated, remote attacker can exploit this to bypass authentication and execute arbitrary commands. \n\nLog4j 1.x, which reached its End of Life prior to 2016, comes with JMSAppender which will perform a JNDI lookup if enabled in Log4j’s configuration file, hence customers should evaluate triggers in 1.x based on the risk that it is EOL and whether JNDI lookups are enabled.\n\nNote that Nessus has not tested for these issues but has instead relied only on the application’s self-reported version number.

How should this be resolved?

As was stated in the other thread. Jenkins doesn’t use log4j, so its not vulnerable to log4j exploits. The blog post your replying to lists ways to test if your install has it. To remedy things, uninstall any plugins that are using it. Or update and hope said plugins got fixed.