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.
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
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.
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:
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
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.
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.