Updates and actions to address Log4j CVE 2021 44228 and CVE 2021 45046 in GitLab

gitlab ·
Dec 15, 2021 · 5 min read · Leave a comment

Updated 8:00 PM UTC January 05,2022

TL;DR: We have investigated the new Log4j vulnerability, CVE-2021-44832, and have determined that this is a low impact to the GitLab platform and our customers. We will continue to monitor this situation closely and will continue to keep you informed.

On 2021-12-28, version 2.17.1 of Apache Log4j was released, containing a fix for CVE-2021-44832. This vulnerability does not pose a significant risk to GitLab Self-managed or SaaS offerings. As mentioned in previous updates, we are planning on updating Log4j in SAST and Dependency Scanning analyzers GitLab 14.7 scheduled for January 22, 2022. We will now be targeting version Log4j 2.17.1 for these updates.


Updated 10:45 PM UTC December 21, 2021

TL;DR: We have investigated the new Log4j denial of service vulnerability, CVE-2021-45105, and have determined that this is a low impact to the GitLab platform and our customers. We will continue to monitor this situation closely and will continue to keep you informed.

Users with default configurations of SAST and Dependency scanning of GitLab Self-managed and SaaS are at very low risk for Log4j vulnerabilities. If you are not running default configurations, please read on for recommended actions.

We’ve established that exploitation of this vulnerability in GitLab does not impact confidentiality, integrity, or availability of customer data. If exploited, an attacker would be able to crash the SAST or Dependency Scanning analyzer that’s currently running in a CI job only. Exploitation requires privileged access to the running CI job. Additionally, exploitation requires a specific set of Log4j configurations, and GitLab deploys Log4j in a default configuration during CI job operations that require it.

Due to the low level of risk involved here, we plan to update Log4j in SAST and Dependency Scanning analyzers to v2.17.1 in GitLab 14.7 scheduled for January 22, 2022. Should this situation change, we will update customers immediately.


Updated 12:30 AM UTC December 18, 2021

On 2021-12-16 the Scala programming language announced that sbt includes a Log4j dependency that is vulnerable to CVE-2021-44228, although it is not enabled by default. The Spotbugs SAST analyzer for Java, Scala, Groovy, and Kotlin code includes sbt. GitLab has updated the sbt version in this analyzer to version 1.5.7, which includes an updated version of Log4j. By default, this analyzer only runs when Java, Scala, Groovy, or Kotlin language code is detected, and sbt is only invoked when Scala code is found.

For those running Spotbugs with default configurations for SAST, no action is needed.

Action needed:

We’ve updated the contents of this blog post to reflect this new finding and fix. 2021-12-18 updates are in italics below.


We want to share the actions we’ve taken in response to the Log4j remote code execution vulnerabilities CVE-2021-44228 and CVE-2021-45046. Upon becoming aware of the vulnerabilities, we immediately mobilized our Security and Engineering teams to determine usage of this software component and its potential impact within our product, across our company, and within our third-party software landscape. Our teams have continued to investigate and monitor the situation over the past few days and it has since become known that the following third-party software dependencies used in our SAST and Dependency Scanning features include the vulnerable Log4j libraries:

At this time, no malicious activity, exploitation, or indicators of compromise have been identified on GitLab.com.

Actions we have taken to address the Log4j vulnerabilities

Default configurations for SAST and Dependency Scanning are fully patched

Our teams are continuing to investigate this issue to ensure that our products and customers are secure. We will provide further communication if additional risks are identified.

Questions and more information

If you have questions, you can post them to this related forum thread. Customers with an active support contract can also open a support ticket. See our related blog post for information on how to use GitLab security features to detect Log4j vulnerabilities.

Get the latest updates

“Updated 2022-01-05: Actions GitLab has taken to investigate and mitigate the impact of Log4j, and actions GitLab users can take.” – gitlab

Click to tweet

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license