Privacy Ninja

Log4j 2.17.1 Out Now, Fixes New Remote Code Execution Bug

Log4j 2.17.1 Out Now, Fixes New Remote Code Execution Bug

Apache has released another Log4j version, 2.17.1 fixing a newly discovered remote code execution (RCE) vulnerability in 2.17.0, tracked as CVE-2021-44832.

Prior to today, 2.17.0 was the most recent version of Log4j and deemed the safest release to upgrade to, but that advice has now evolved.

Fifth Log4j CVE in under a month

Mass exploitation of the original Log4Shell vulnerability (CVE-2021-44228) by threat actors began around December 9th, when a PoC exploit for it surfaced on GitHub.

Given Log4j’s vast usage in the majority of Java applications, Log4Shell soon turned into a nightmare for enterprises and governments worldwide.

Also Read: Key PDPA Amendments 2019/2020 You Should Know

While the critical risk posed by the original Log4Shell exploit is paramount, milder variants of the vulnerability emerged in Log4j versions, including 2.15 and 2.16—previously believed to be fully patched.

BleepingComputer earlier reported on four different CVEs impacting Log4j and one discovered in the ‘logback’ framework. After the discovery of a DoS flaw in version 2.16, the advice had swiftly shifted towards upgrading to version 2.17.0, deemed the safest of all.

But now a fifth vulnerability—an RCE flaw, tracked as CVE-2021-44832 has been discovered in 2.17.0, with a patch applied to the newest release 2.17.1 which is out.

Rated ‘Moderate’ in severity and assigned a 6.6 score on the CVSS scale, the vulnerability stems from the lack of additional controls on JDNI access in log4j.

“JDBC Appender should use JndiManager when accessing JNDI. JNDI access should be controlled via a system property,” states the issue description seen by BleepingComputer.

“Related to CVE-2021-44832 where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.”

Checkmarx security researcher Yaniv Nizry claimed credit for reporting the vulnerability to Apache:

Nizry’s tweet quickly exploded in traffic, attracting remarks and memes from security experts and ‘victims’ of the ongoing log4j-patching fatigue.

“I hope this is a joke, I hope so much Pensive face #log4j,” tweeted one user in response.

“We are LONG past the point where the only responsible thing to do is put up a giant flashing neon sign that reads ‘LOG4J CANNOT BE FIXED, DO NOT USE IT FOR ANYTHING.'” taunted another.

Also Read: The 5 Benefits Of Outsourcing Data Protection Officer Service

Security expert Kevin Beaumont labeled the instance another “failed Log4j disclosure in motion” during the holidays.

Disclosed too soon?

At the time of Nizry’s tweet, BleepingComputer did not see an official advisory or memo indicating the presence of an RCE bug in log4j 2.17.

The tweet itself contained no details about the vulnerability or how it could be exploited but, within minutes, led a pack of security pros and netizens to start investigating the claim.

Disclosing security vulnerabilities prematurely can lure threat actors to conduct malicious scanning and exploitation activities, as evident from the Log4Shell exploit leak of December 9th.

Marc Rogers, VP of cybersecurity at Okta first disclosed the vulnerability identifier (CVE-2021-44832) and that the exploitation of the bug depends on a non-default log4j setup where configuration is being loaded from a remote server:

Up until now, log4j vulnerabilities have been exploited by all kinds of threat actors from state-backed hackers to ransomware gangs and others to inject Monero miners on vulnerable systems.

The Conti ransomware gang has been seen  eying vulnerable VMWare vCenter servers. Whereas, attackers breaching Vietnamese crypto platform ONUS via log4shell demanded a $5 million ransom

Log4j users should immediately upgrade to the latest release 2.17.1 (for Java 8). Backported versions 2.12.4 (Java 7) and 2.3.2 (Java 6) containing the fix are also expected to be released shortly.

BleepingComputer has reached out to Checkmarx for comment in advance of writing and we are awaiting their response.

Update 4:45 PM ET: Checkmarx has published a blog post describing the vulnerability.

Outsourced Data Protection Officer – It is mandatory to appoint a Data Protection Officer. We help our clients quickly comply with their PDPA & data protection requirements.

Vulnerability Assessment Penetration Testing – Find loopholes in your websites, mobile apps or systems.

Smart Contract Audit – Leverage our industry-leading suite of blockchain security analysis tools, combined with hands-on review from our veteran smart contract auditors.


Leave a Reply

Your email address will not be published. Required fields are marked *


Subscribe to our mailing list to get free tips on Data Protection and Data Privacy updates weekly!

Personal Data Protection


We have assisted numerous companies to prepare proper and accurate reports to PDPC to minimise financial penalties.

Powered by WhatsApp Chat

× Chat with us