.svg)
.svg)
Log4Shell is a remote code execution vulnerability in Apache Log4j 2, tracked as CVE-2021-44228, that allowed an attacker to run arbitrary code on a server by supplying text that the application then wrote to its log. NVD analysts assessed it at 10.0 on the CVSS 3.1 scale, the highest score available.
Apache credits the discovery to Chen Zhaojun of the Alibaba Cloud Security Team, whose private report reached the foundation's security list on 24 November 2021. Disclosure became public on 9 December, and CISA published a statement the following day.
Log4Shell names the vulnerability; Log4j is the Apache Software Foundation logging library that contained it, still in wide use today.
How the Attack Worked
Log4j 2 supports lookups, a syntax that substitutes values into log output at write time. One lookup type resolved JNDI references, including those pointing at an external LDAP server.
A lookup string aimed at an attacker-controlled host, once written to a log, therefore caused Log4j to contact that host, retrieve a Java class, and execute it. No authentication was required, and the attacker needed no access to the target beyond getting their text into something it logged: a username field, an HTTP header, a search query, a chat message.
Only the log4j-core component was affected. Applications that included log4j-api without log4j-core were not vulnerable, a distinction that settled the question for many applications during triage. Log4j 1.x, which has no lookup feature, was not affected by this CVE, though a separate issue involving its JMSAppender was filed as CVE-2021-4104.
Why It Scored 10.0
Exploitation worked over the network, at low complexity, with no privileges and no user interaction. Those four metrics alone produce a critical score.
The metric that took it to the maximum was scope. CVSS raises the ceiling when a vulnerability lets an attacker affect resources beyond the security authority of the component that contains the flaw, and a logging library that executes a remote class hands over the whole application process. Without that scope change, the same vulnerability would have scored 9.8.
The Vulnerabilities That Followed
The fix shipped in 2.15.0 proved incomplete, and three further CVEs were assigned over the following three weeks.
Affected and fixed version ranges differ by Java release, and Apache maintains them on its security page. The last two are not variants of the original flaw: one is a denial of service, and the other requires write access to the logging configuration, a privilege CVE-2021-44228 never needed.
The Government Response
CISA issued Emergency Directive 22-02 on 17 December 2021, requiring federal civilian agencies to assess internet-facing assets and either patch or mitigate. It was closed in April 2022, with its requirements absorbed into BOD 22-01, the standing directive covering the Known Exploited Vulnerabilities catalog.
Log4j became the first subject of the Cyber Safety Review Board, established under Executive Order 14028, in a report published in July 2022. Organizations that responded well, the Board found, knew where they used Log4j and had the processes to act on that knowledge; few could do so at the speed the event demanded. One federal cabinet department reported dedicating 33,000 hours to its response.
The Board's most counterintuitive finding concerned impact. It was aware of no significant Log4j-based attacks on critical infrastructure systems, and judged that exploitation had occurred at lower levels than many experts predicted given the severity. It also stated plainly why that conclusion was difficult to reach: no authoritative source tracks exploitation across industries, many organizations do not collect the data, and reporting is voluntary.
What the Disclosure Timeline Exposed
Alibaba reported the vulnerability to China's Ministry of Industry and Information Technology on 13 December 2021, nineteen days after its engineer disclosed it privately to Apache. MIIT rules require network product providers to report flaws in their own products within two days, a deadline that had passed seventeen days earlier.
From 22 December, media reports indicated that MIIT had suspended Alibaba from a threat information sharing partnership over the delay. The Board could not verify the rationale: no detailed explanation was published, and MIIT did not address the matter when the Board asked.
The Board's broader concern was structural: a rule requiring vendors to notify a government within two days of discovery gives that government knowledge of unpatched vulnerabilities before any fix exists.
Is Log4Shell Still a Risk?
The Board called Log4j an "endemic vulnerability," judging that unpatched instances would persist for many years and possibly a decade or more.
Two conditions sustain that. Versions past end of support still run and will never receive a fix.
And Log4j is frequently embedded in purchased appliances, cloud services, and vendor software, where the operator can neither see the dependency nor upgrade it independently. Practical remediation steps are covered in this guide to patching the Log4j vulnerability.
Could There Be Another Log4Shell?
In August 2026, a deserialization filter bypass in Log4j 2 was published as issue #4255 and framed by its reporter as a path to remote code execution, prompting comparisons that Raven examined in Log4Shell 2.0.
Apache does not treat the filtering mechanism as a security boundary, and its published threat model classifies bypasses of that filter as hardening work instead of project vulnerabilities. No CVE was assigned. Exploitation additionally requires that the application already deserialize attacker-influenced data, which Log4j does not do during normal logging.
A reproducible technique existed while its classification remained unsettled, and any defense keyed to a CVE identifier had nothing to match against. Runtime application security evaluates what code does while it executes, a question that can be answered before an advisory exists.
