A critical security vulnerability has been identified in the popular “Apache Log4j 2” library.
This vulnerability is identified as CVE-2021-44228.
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.
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.
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.
Originally posted on Jenkins Blog