Security Incidents
Log4Shell (CVE-2021-44228)
A remotely exploitable JNDI lookup in Apache Log4j 2, the disclosure-to-exploitation window, and the supply chain behind it.
The flaw
Log4j 2 supported a message lookup mechanism: text written in a log message could be interpreted as a pattern that looked up a value. Combined with a JNDI provider on the classpath, an attacker who can cause a string to be logged — which is most user input, somewhere — can cause the application to make a lookup, and in widely used configurations to instantiate objects from the result.
The two conditions that made it exceptional:
- Reachability. Any application that logs user-controlled text was potentially vulnerable, which is a large set of applications.
- Invisibility. Log4j configuration is frequently not under the control of the team deploying the application, and a vulnerable copy can be present without anyone on the team knowing.
Timeline
| Date | Event |
|---|---|
| 2021-12-09 | Public disclosure; Apache Log4j 2.15.0 released |
| 2021-12-10 | Further vector found in 2.15.0; 2.16.0 released |
| 2021-12-13 | 2.17.0 released, completing the fixes for the family |
| 2021-12 | CISA and national CERTs issue alerts; the vulnerability is added to the Known Exploited Vulnerabilities catalog |
The short interval between disclosure and observed exploitation is the finding that matters most for practice, and it is the reason automatic updates are not optional.
The second-order lesson
The interesting part of this incident is not the vulnerability. It is that a large proportion of affected organisations discovered they had a vulnerable copy of a library they had never chosen, had never audited, and could not have removed in time. The practical response was to inventory rather than to patch, because the first question was always “where is this dependency”.
What this entry does not claim
- No victim count. The published figures come from research scanning, they disagree substantially, and none of them is a census. Anyone quoting a single definitive number is quoting a scan.
- No confirmed attribution of any specific incident to Log4Shell in this entry. Individual crime reports have been linked by investigators, but that linkage belongs in an entry about that incident, with its own evidence.
Sources
- NVD: CVE-2021-44228 — the record, with CVSS scoring and references.
- Apache Log4j security page — the project’s own list of affected versions, fixed versions, and mitigations. Authoritative for “is this version vulnerable”.
- CISA advisory AA21-356A — the government response and recommended mitigations.
Claim labels
FACT
The vulnerability is tracked as CVE-2021-44228 in the National Vulnerability Database.
FACT
It affects Apache Log4j 2 versions 2.0-beta9 through 2.14.1, as stated in the Apache Log4j project security advisory.
FACT
The flaw was in the message lookup mechanism, where a logged string could be interpreted as a format pattern that triggered a JNDI lookup.
FACT
Apache Log4j 2.15.0 removed the behaviour, and 2.16.0 was released to remove a further vector found in 2.15.0, with 2.17.0 completing the fixes for the family of issues.
FACT
The flaw was also present in products that bundled Log4j rather than exposing it directly, and Apache published a list of affected third-party products.
FACT
Log4j is maintained by the Apache Software Foundation, and Log4j 1.x reached end of life before this incident.
RESEARCHER ANALYSIS
Scanning studies published by researchers in December 2021 estimated that a very large number of internet-facing services were running a vulnerable version. The estimates differ by an order of magnitude between studies, and none is an authoritative count.
EDITORIAL
This entry takes the view that the incident is a supply chain and maintenance problem rather than a vulnerability problem: a mature, widely deployed, end-of-life logging library was in the dependency tree of a large fraction of the industry.
Sources
Last link check: 2026-09-27. A link check confirms reachability, not that every claim has been independently reviewed.