On Thursday, December 9, 2021, GitHub was made aware of a vulnerability in the Log4j logging framework, CVE-2021-44228.
Today we released new versions of GitHub Enterprise Server (3.3.2, 3.2.7, 3.1.15, 3.0.23), which update our Log4j dependency to version 2.17.1. Our initial configuration-based mitigation, detailed and released in GitHub Enterprise Server versions 3.3.1, 3.2.6, 3.1.14, and 3.0.22, still fully mitigates the risk of the Log4j vulnerabilities CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832. We elected to update to this latest version of Log4j as part of our normal release cycle. This upgrade will decrease false positives from file-based vulnerability scanners.
GitHub is tracking the latest updates regarding Log4j 2.15 and the subsequent release of Log4j 2.16 and CVE-2021-45046. This week, we have continued to monitor the impact of these variants across our products and infrastructure. Additionally, the GitHub Security Lab has engaged in further analysis to understand our products’ exposure and to actively review and evaluate the effectiveness of our previous mitigations. At this time, we have not identified any additional risk or exposure to GitHub internally or to our products.
Detailed updates for our products are below, with no new action required by users at this time.
Elasticsearch is currently the only known exposure to Log4j vulnerabilities in GitHub Enterprise Server. We have internally validated that our mitigation approach for CVE-2021-44228 in GitHub Enterprise Server (released on December 13 in patch version 3.3.1, 3.2.6, 3.1.14, and 3.0.22) also mitigates CVE-2021-45046 and other currently-published variants impacting Log4j. Our releases follow Elasticsearch’s mitigation suggestions and do not require an immediate update to Log4j 2.16.
The mitigations detailed in our December 13, 2021 post below remain effective and should be followed to secure instances of GitHub Enterprise Server.
On December 14, we finalized our rollout of mitigations for our use of Elasticsearch within GitHub.com and GitHub Enterprise Cloud. We validated this mitigation protects against both CVE-2021-44228 and CVE-2021-45046 in the context of Elasticsearch’s use of Log4j. No exploitation has been identified due to our use of Elasticsearch.
In addition to Elasticsearch, we have continued investigating our impact from other third-party services in our infrastructure and are rolling out remediation and vendor recommendations as they become available. We are actively monitoring our telemetry for signs of exploitation and have not detected any successful exploitation at this time.
On Thursday, December 9, 2021, GitHub was made aware of a vulnerability in the Log4j logging framework, CVE-2021-44228. We immediately initiated our incident response process to determine our usage of this framework and its impact across GitHub, our products, and our infrastructure. To assist the community in identifying their usage of the vulnerable Log4j library, we also issued a GitHub Security Advisory and Dependabot alerts containing general vulnerability details.
This post summarizes the results of our investigation to date and our recommended next steps for customers.
In GitHub Enterprise Server’s recommended configuration, CVE-2021-44228 is only exposed to authenticated users. If an instance has been configured to not use private mode, this vulnerability may also be exposed to unauthenticated users. Customers should consider immediately taking one of two steps below to secure their instances of GitHub Enterprise Server.
Following the public vulnerability disclosure, we took immediate action on the evening of Friday, December 10 to begin mitigating any impact to GitHub.com and GitHub Enterprise Cloud. We reviewed telemetry and deployed additional monitoring, neither of which have detected any successful exploitation at this time. We continue to monitor the situation for any new developments. No action by users of GitHub.com or GitHub Enterprise Cloud is required in order to continue safely using GitHub.com.
We are continuing to investigate our exposure to this vulnerability and will provide further updates if any new risk to our users or our products is identified.
We’ve dramatically increased 2FA adoption on GitHub as part of our responsibility to make the software ecosystem more secure. Read on to learn how we secured millions of developers and why we’re urging more organizations to join us in these efforts.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
Jill Moné-Corallo 
