Editor's note, October 2026: This article was first published in January 2022. Apache fixed CVE-2021-44228 in Log4j 2.15.0 and closed several follow-up vulnerabilities in later releases up to 2.17.1 in December 2021; the current status is on the Apache Logging Services security page. CVE-2021-44228 has been listed in CISA's Known Exploited Vulnerabilities catalog since 10 December 2021, with known use in ransomware campaigns, so older applications and appliances that still bundle an affected version remain a target. Log4j 1.x reached end of life in 2015 and receives no fixes. CISA's GitHub list of affected vendors has since been archived and is no longer updated.
On December 9, 2021, a vulnerability in Apache Log4j was published and later designated CVE-2021-44228. If exploited, it allows attackers to execute code on affected systems remotely, which is known as remote code execution.
Exploit code, nicknamed Log4Shell, quickly became publicly available, and CISA and its partners reported active, widespread exploitation; its Log4j guidance collects the details. According to security specialists, the vulnerability can be used to distribute malware and ransomware, steal sensitive data such as credit card, social security and healthcare data, and carry out other attacks.
Apache Log4j is a free, open-source, Java-based logging library distributed under the Apache License. Applications use it to record events and pass diagnostic messages to administrators and users, for example a log entry noting that a web server returned a 404 error after someone clicked a broken link. That makes it a basic building block in a huge number of Java applications.
Systems running Apache Log4j 2 versions from 2.0-beta9 up to and including 2.14.1 are potentially at risk if they log data that an attacker can influence, directly or indirectly. Systems exposed to the internet are the most obvious targets, but internal systems that log data passed on from elsewhere can be affected too. Logging is a fundamental feature, and Log4j is used in enterprise and open-source software of all kinds, including web servers, email services and cloud services; Apple iCloud and Amazon Web Services (AWS) were reportedly among those affected. Because AWS hosts a vast number of third-party services, the potential attack surface was enormous.
At the time, our management and monitoring solution ISEC7 SPHERE used Log4j but was not affected by the vulnerability. As a precaution, we removed Log4j from the solution entirely and replaced it with Logback.
CISA also maintained a list of affected vendors in a GitHub repository, which has since been archived.
Even the most innocuous library can become an attack vector. How do you keep track of an environment with hundreds of servers and thousands of users and devices, make sure it is protected against preventable attacks, and respond quickly when a new CVE appears? We looked at the patching side in Security Breach: Patch or Clash and at what happens after an incident in Security Breach: It Could Happen to You. A similar case from the same year is our advisory on the CISA emergency directive for VMware vulnerabilities, and Lessons Learned from a Major Hack shows how attacks unfold in practice.
Want to know which versions run in your environment and which of them have known vulnerabilities? ISEC7 SPHERE compares them with the National Vulnerability Database and alerts you when a CVE becomes known. Contact us to take the next steps in securing your infrastructure.