CISA-linked reporting places exploitation of the Apache Log4j flaw on or around December 1, 2021—before public disclosure triggered global scanning for vulnerable installations. That date anchors Log4Shell on the timeline. Chen Zhaojun of the Alibaba Cloud Security Team had reported the flaw to Apache on November 24, 2021; public disclosure followed on December 9; CISA added it to the Known Exploited Vulnerabilities catalog on December 10; and Emergency Directive 22-02 arrived on December 17.
Log4Shell earned a CVSS 10.0 (Critical), with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. But its real significance was not the score—it was where the vulnerable code lived: everywhere, and often in places nobody had inventoried.
CVE-2021-44228 is a flaw in Apache Log4j 2, specifically the log4j-core library. The versions consistently identified as vulnerable in CISA and Apache-derived reporting are 2.0-beta9 through 2.14.1. NVD associates the weakness with improper expression-language neutralization, input-validation, resource-consumption and deserialization issues. The impact was unauthenticated remote code execution under vulnerable configurations.
There is a version subtlety worth stating precisely. One NVD summary describes the range through 2.15.0, while the primary vulnerability reporting identifies 2.0-beta9 through 2.14.1 and notes that 2.15.0 disabled the original behavior by default. The accurate way to present this is to state the established original vulnerable range, then explain separately that 2.15.0 proved insufficient against a related follow-on issue—rather than silently expanding the original range.
Logging normally looks passive: an application receives data and writes a representation of it. Vulnerable Log4j versions made logging active by supporting message lookup substitution. Certain character sequences in a string could instruct the library to resolve a value through Java Naming and Directory Interface (JNDI) services.
If attacker-controlled input reached a logged field, Log4j could interpret it as a lookup rather than inert text. A JNDI lookup could make the application connect to an adversary-controlled LDAP or related endpoint and, in vulnerable conditions, load and execute attacker-supplied Java code. The dangerous input did not have to arrive through an explicitly privileged API—any request element copied into a log, such as a header, a username, or chat text, could become relevant.
That crossing of an architectural boundary is the heart of the bug: untrusted application data flowed into a general-purpose logging dependency, and the dependency treated the data as executable instructions. It is worth resisting the urge to present a single literal lookup string as "the exploit"—delivery and runtime behavior varied widely across observed attacks.
Exploitation reportedly began around December 1, before the December 9 public disclosure. After disclosure, the FBI observed widespread scanning and rapid incorporation of the flaw into existing criminal schemes, including obfuscated probes designed to slip past naive filters.
Threat actors used Log4Shell for cryptomining, botnet recruitment, information theft and ransomware deployment. State-sponsored actors also used it against unpatched public-facing systems, including VMware Horizon servers, followed by lateral movement and data exfiltration. There is no single actor attribution, because the vulnerability became a general-purpose entry method available to anyone.
CISA-associated reporting estimated that hundreds of millions of devices were impacted, while another estimate suggested one in ten digital assets might be vulnerable. These are vulnerability or exposure estimates—not confirmed compromises. Reading "hundreds of millions of devices" as "hundreds of millions of breaches" would badly distort the record.
The library's presence across enterprise services, cloud platforms and operational-technology products made inventory the central problem. An organization could patch its own application code and still remain exposed through packaged vendor software, nested Java archives, or an appliance containing an undisclosed copy. No reliable global compromise total exists; the defensible statement is that exploitation and scanning were widespread, and the affected dependency was embedded across a vast software ecosystem.
Building a home lab to test dependency scanners and reproduce JNDI callbacks safely takes portable, isolated storage. The Samsung T7 Portable SSD is fast external storage for offline test environments and artifact archives.
Amazon Affiliate Link
The remediation sequence was iterative, and its zig-zag is itself instructive:
Temporary measures included removing JndiLookup.class or, for some versions, setting log4j2.formatMsgNoLookups to true. CISA required federal agencies to inventory solution stacks, patch or mitigate internet-facing systems, remove systems where mitigation was unavailable, and report their status. Throughout, CVE-2021-44228 should be kept separate from the later Log4j-family CVEs it spawned.
Log4Shell made software composition an incident-response issue. A flaw in a logging library became an enterprise-wide emergency precisely because dependency presence was so poorly inventoried—teams could not fix what they did not know they were running.
The U.S. Cyber Safety Review Board later characterized Log4j as an "endemic" vulnerability whose risk would persist for years. That finding shifted the frame from a single emergency patch to durable practices: software bills of materials, dependency visibility, vendor communication and repeatable asset discovery. The one-line summary still holds: logging became code execution—and nobody knew where the logger was.