As previously predicted to unfold, at approximately 7:35 PM GMT, 28th of December 2021, another security vulnerability impacting the Log4j logging library was published as CVE-2021-44832. 

This new CVE-2021-44832 security vulnerability is affecting versions up to 2.17.0, which was previously thought to be fixed. This vulnerability is similar in nature to CVE-2021-4104 which affected the 1.x branch of Log4j.

The impact of CVE-2021-44832

If you are able to swiftly upgrade to the latest fixed version of Log4j then you should follow that path. That said, we’d like to point out that this specific ​​CVE-2021-44832 vulnerability has been assigned a medium 6.6 CVSS score and requires considerably elevated pre-conditions for an attacker to exploit successfully.

​​CVE-2021-44832 deems Log4j 2.17.0 (and older versions) to be vulnerable to code execution if an attacker is able to control, and modify, the contents of the logging configuration file to then point to a remote URI data source to load arbitrary Java code.

The fix in 2.17.1, and backported to older JVM-compatible versions of the library, mitigated that vulnerability by restricting the JNDI data source in the configuration file to only allow the use of the Java protocol, and disallow any remote network calls to be made.

Immediate steps you should take to fix CVE-2021-44832

The Log4j team published fixes for this security vulnerability:

• If you’re on Java 8 and later you should upgrade to Log4j 2.17.1
• If you’re on the 2.12.x branch for Java 7, upgrade to Log4j 2.12.4
• If you’re on the 2.3.x branch for Java 6, upgrade to Log4j 2.3.2

A storm of prematurely leaked Log4j vulnerabilities

The disclosure of this vulnerability, has followed an increasingly worrying trend in irresponsible disclosures in Log4j, where security researchers have leaked details of the vulnerabilities they have disclosed before maintainers have had time to properly fix the issue and publish new releases. 

This problematic phenomenon started with the original Log4j RCE wherein researchers leaked details and even a proof of concept of the vulnerability on Twitter and GitHub, hours before the official disclosure (see our timeline). Yet again, the existence of this vulnerability was leaked on Twitter several hours before the official release, by a security researcher claiming credit for the finding.

It would appear that in both cases, the leaking of information, while probably without malicious intent, has led to a rushed release on behalf of Apache (which could leave the door open for additional vulnerabilities and bugs in the new release). Additionally, in this specific instance we can assume that given a choice, Apache would have not chosen to rush out a release at a time of year where many organizations have extended holidays and would therefore be less able to quickly triage and remediate the issue if needed. 

Open source security is increasingly important to the world at large and responsible disclosure practice is a cornerstone of our community’s ongoing security. We hope that any future disclosures in Log4j or other open source packages can be more safely handled going forward. 

As always, we at Snyk, remain committed to our responsible disclosure program, while also staying vigilant to any potential emerging threats and providing quick and actionable information to our users and the open source community at large.

Log4Shell resource center

We’ve created an extensive library of Log4Shell resources to help you understand, find and fix this Log4j vulnerability.