Use GitHub’s security features to assess Apache Log4j exposure and, where possible, mitigate this vulnerability within your GitHub repositories.
The world is reacting to the news that a popular Java library, Apache Log4j, contains a vulnerability in versions prior to 2.16.0. When exploited, that vulnerability can result in attackers being able to remotely execute code on the victim’s system. GitHub’s security team recently shared how we’ve responded to this issue on GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. In this blog post, we’ll tell you more about how you can use GitHub’s security features to help assess and address your exposure.
Currently, the best-known solution to mitigate any exposure from this vulnerability is to upgrade to Log4j version 2.16.0 in your application. If you’re unable to update to version 2.16.0, we recommend mitigating by ensuring the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components of your application.
If you’re a GitHub user and are using Maven to manage your Java dependencies, you can use GitHub Dependabot to surface all locations Log4j is explicitly declared as a dependency. To enable Dependabot, see the documentation linked at the bottom of this post. Once enabled, you will receive alerts and pull requests to upgrade to the patched Log4j version. GitHub has sent over 175,000 alerts and pull requests for this vulnerability already.
After enabling Dependabot, you can view an organization or server-wide list of alerts for the Log4j vulnerability using the Advisory Database:
If you use Gradle or another mechanism to manage your Java dependencies, Dependabot will not alert for those repositories. GitHub is continuously working to add enhancements, including Gradle support to Dependabot alerts, to see more details visit our public roadmap.
If you’re a GitHub Advanced Security customer or if you maintain a public open source project, we’ve developed an experimental CodeQL query that you can run to identify potentially affected lines of code in your GitHub repositories. The query will detect situations in which untrusted user data flows into Log4j logging statements. If a codebase depends on a vulnerable Log4j version, any alerts generated by this query almost certainly indicate a security risk.
You can run the CodeQL query by using the CodeQL CLI, or you can enable the query in GitHub code scanning by configuring a custom query using the queries directive in your CodeQL workflow configuration:
As the industry works quickly to assess exposure and patch, GitHub recommends for users to enable Dependabot as part of their overall response. While this will not provide a complete picture of exposure, it will very quickly identify explicit dependencies that can be patched rapidly. For GitHub Advanced Security users, the provided experimental CodeQL query can also help.
If you need help to enable Dependabot or GitHub code scanning along with CodeQL, please refer to the documentation below or talk to one of our security specialists for further advice or a GitHub Advanced Security Demo.
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.
With push protection now enabled by default, GitHub helps open source developers safeguard their secrets, and their reputations.
Brittany O'Shea 
