Due to the recently discovered Log4Shell vulnerability, and to support the tremendous effort being mounted by the community to address it, we are happy to announce that we are increasing the free test limit in Snyk Open Source! This means that any developer, no matter the company or project, can now use Snyk Open Source to find and fix Log4Shell with double the number of free tests, whether it’s within your IDE, your Git repositories, CI environments, or using the Snyk CLI.

Just a few days after CVE-2021-45046 was released and fixed, a third zero-day vulnerability was discovered in Apache Log4j, tracked as CVE-2021-45105. The bug was reported on December 15, 2021, and disclosed on December 18, 2021. This third vulnerability has received a CVSS score of 7.5 out of 10, whereas the first one known as Log4Shell (CVE-2021-44228) received the maximum CVSS score of 10 due to its criticality.

Welcome to Elastic’s Log4j2 vulnerability information hub. Here we will explain what the specific Log4j2 vulnerability is, why it matters, and what tools and resources Elastic is providing to help negate the opportunity for malware exploits, cyberattacks, and other cybersecurity risks stemming from Log4j2.

A third Log4j2 vulnerability was disclosed the night between Dec 17 and 18 by the Apache security team, and was given the ID of CVE-2021-45105. According to the security advisory, 2.16.0, which fixed the two previous vulnerabilities, is susceptible to a DoS attack caused by a Stack-Overflow in Context Lookups in the configuration file’s layout patterns. What is this CVE about? What can you do to fix it? How does it differ from the previous CVEs?

Overnight, it was disclosed by Apache that Log4j version 2.16 is also vulnerable by way of a Denial of Service attack with the impact being a full application crash, the severity for this is classified as High (7.5). Snyk is currently not aware of any fully-fledged PoCs or exploits in circulation. CVE-2021-45105 has been issued, and a new fixed version (2.17) has been published by Apache which we recommend upgrading to.

We have published an initial blog on the Log4j exploit and a followup blog with a second detection method for detecting the first stage of exploits occurring over LDAP. Today, we will discuss a third detection method, this one focused on the second-stage download that happens after the first stage completes. In this case, the JVM will download additional Java code payloads over HTTP.

There's little question that you've already heard about the recently discovered security flaw related to Log4j, a widely used Java library for logging error messages in applications. The vulnerability enables a threat actor to remotely execute commands via remote code execution (RCE) on nearly any machine using Log4j. But it's also important to cut through all of the noise to truly understand the implications of the Log4j and what organizations can do to combat it.

After successful deployment to Arctic Wolf’s customer community of more than 2,300 organizations worldwide, today we are making “Log4Shell Deep Scan” publicly available on GitHub. Log4Shell Deep Scan enables detection of both CVE-2021-45046 and CVE-2021-44228 within nested JAR files, as well as WAR and EAR files.