Contrary to initial assessments that labeled the Log4Shell vulnerability as one of the most critical and widespread, security researchers from VulnCheck argue that the fears surrounding it were “overblown and exaggerated.” Log4Shell, rated as CVSS 10.0, was considered a significant threat due to its ease of exploitation, enabling remote code execution in various applications utilizing the Log4j logging utility. However, VulnCheck’s recent report challenges this perception, suggesting that, at the time, very few products with the vulnerable Log4j libraries were remotely exploitable for code execution.
VulnCheck identified a specific set of products that were remotely exploitable using Log4Shell, including Apache Druid, Apache James, Apache JSPWiki, Apache OFbiz, Apache Skywalking, Apache Solr, Apache Struts2, Ivanti MobileIron, ManageEngine ADManager, Ubiquiti UniFi Controller, VMware Horizon, and VMware vCenter. The report emphasized that this list represents the “majority” of products remotely exploitable, and only a subset of them has been linked to exploitation in the wild. VulnCheck currently associates Log4Shell exploitation with 40 APT, ransomware groups, and/or botnets, with only four of the products (MobileIron, Ubiquiti UniFi Controller, VMware Horizon, and VMware vCenter) being associated with those attacks.
The complexity of Log4Shell exploitation, involving a two-stage attack, contributes to its limited impact. The first stage triggers a connection to an attacker-controlled server, but this alone does not achieve code execution. The second stage requires the attacker-controlled server to provide new code for the victim to execute, and VulnCheck notes that completing this second stage is a non-trivial task in Java. As of December 7, VulnCheck reported that there were only 125,000 hosts potentially vulnerable to Log4Shell, with 94% of them already patched, leaving just 7,000 potentially vulnerable hosts, taking into account undiscoverable versions and other factors.
In summary, VulnCheck’s report challenges the prevailing narrative about the severity and widespread exploitation of the Log4Shell vulnerability, asserting that the actual impact was more limited than initially perceived. The complexity of the exploitation process, combined with the effective patching of vulnerable systems, contributed to mitigating the potential risks associated with Log4Shell.
