Log4Shell: one log line that gave the internet remote code execution

What happened

On December 10, 2021, a vulnerability was published in Apache Log4j, the most widely used Java logging library. Tracked as CVE-2021-44228 and nicknamed "Log4Shell," it carried the maximum CVSS score of 10.0. Any application that logged a string an attacker could influence — a User-Agent header, a username field, a chat message — could be forced to execute arbitrary code. Because Log4j is embedded in countless enterprise applications, cloud services, and appliances, the flaw affected an enormous share of the internet at once. CISA added it to the Known Exploited Vulnerabilities catalog with a mandatory remediation deadline of December 24, 2021.

The affected versions ran from 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1). Exploitation was trivial and required no authentication, so mass scanning began within hours of disclosure.

Root cause

Log4j supported a message-lookup feature that interpreted special syntax inside log messages. When it encountered a JNDI lookup such as a reference to an external LDAP endpoint, it would fetch and process attacker-controlled data — including remote Java classes — and execute it. The library "did not protect against attacker controlled LDAP and other JNDI related endpoints." This maps to CWE-917 (expression-language injection) and, because the danger arrived through a trusted third-party dependency, to OWASP's Software Supply Chain Failures category.

How it would have been caught

Software composition analysis (SCA) tools that inventory dependencies would have flagged the vulnerable Log4j versions the moment the CVE was published. A reproduction sends a crafted string containing a JNDI reference to any input that gets logged, stands up a listener, and confirms the server calls back — proving code execution rather than merely a log entry.

How to prevent it

• Maintain a software bill of materials (SBOM) so every dependency and its version is known and can be searched instantly when a CVE lands.
• Upgrade Log4j to 2.16.0 or later, or remove the JndiLookup class; disabling message lookups alone was insufficient in early mitigations.
• Restrict outbound network access from application servers so a compromised process cannot reach an attacker's LDAP or HTTP endpoint.
• Treat every logged value as untrusted input, and keep third-party libraries patched on a defined cadence.

The Breachwire test (red → green)

Send a request whose logged field contains a JNDI lookup pointing at a listener you control, and confirm the vulnerable server connects back and executes the payload — the RED control. Upgrade the library (or strip the JndiLookup class), replay the identical request, and confirm the string is now logged as inert literal text with no outbound callback, while normal logging still works.