Log4j 2.17.1 out now, fixes new remote code execution bug

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.

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.

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: