Why a logging library ran attacker code: Log4Shell explained

Log4Shell, CVE-2021-44228, existed because Log4j's JNDI features resolved variables found in log messages and parameters without protecting against attacker-controlled endpoints. If an attacker could get a crafted string into anything that was logged, the library could be steered to fetch and run code from a server the attacker chose.

The surprising part: logging is input handling

Most developers think of a logger as a place where data goes out. Log4j also interpreted parts of the text it was given. A string with a particular lookup syntax was not written down as plain text. It was evaluated.

That turned every place a logged value could be influenced into a possible entry point. Request headers, usernames, search boxes and error messages are all things applications routinely log. An attacker did not need to find a special endpoint, only a code path that logged what they sent.

What the maintainers and CISA say

The Apache Log4j security page describes the issue this way: JNDI features used in configuration, log messages and parameters did not protect against attacker-controlled LDAP and other JNDI endpoints. An attacker who controlled log messages or parameters could execute arbitrary code loaded from LDAP servers. It credits Chen Zhaojun of the Alibaba Cloud Security Team with the report and gives the issue a CVSS 3.x score of 10.0.

CISA's advisory AA21-356A says the affected range for this CVE was Log4j 2.0-beta9 through 2.14.1 and that disclosure came on 10 December 2021. It also reports that exploitation was believed to have started around 1 December, before disclosure.

Which part of Log4j was affected

Only the log4j-core JAR was affected, according to the Apache page. An application that uses only log4j-api is not. This is a useful detail when you are triaging, because dependency trees often include the API without the core.

Why patching Java was not enough

CISA's advisory is blunt: patching or updating Java is not enough, you must upgrade the Log4j library itself. The library is often bundled inside other products, so the work was less about one upgrade and more about finding every copy.

What defenders were told to do

• Inventory every asset that uses Log4j, including cloud assets, and treat versions as vulnerable until verified.
• Upgrade to a fixed release. For Java 8 or later, CISA's later guidance points to 2.17.0 or newer.
• Block outbound LDAP, RMI and DNS from application servers where feasible, using allowlists.
• Treat suspected vulnerable systems as compromised until verified, and hunt for configuration changes made since 1 December.
• Use removing JndiLookup.class as a temporary workaround only, because it can cause side effects.

What to take from it

Any component that interprets strings is a parser, and parsers need to be treated as attack surface. Reachability matters too: a vulnerable function that no attacker input can reach is a lower priority than one that logs request headers. Safeguard's reachability analysis helps separate the two. See the companion posts on three CVEs in one week and finding Log4j everywhere.

Quick check

Sources

• Apache Log4j security page
• CISA advisory AA21-356A

Last reviewed: 19 October 2026.