CVE-2021-44228 Log4Shell: Two Years Later, Still Not Patched
A retrospective on Log4Shell, the vulnerability that shook the internet in late 2021, and why a disturbing number of systems remain vulnerable years after a patch was available.
Introduction
When Log4Shell dropped in December 2021, the security community described it as one of the worst vulnerabilities ever discovered. A remote code execution flaw in Log4j, a logging library embedded in thousands of Java applications, with a trivially simple exploit string.
Two years later, scans still find unpatched instances. This is a story about why vulnerability management is harder than it looks.
What Made Log4Shell Different
Most critical vulnerabilities require some form of authentication or user interaction. Log4Shell required neither. Any input field that eventually got logged — a username, a User-Agent header, a search query — was potentially a trigger.
The exploit string caused the vulnerable Log4j library to make an outbound LDAP request to an attacker-controlled server, which responded with a Java class that executed arbitrary code in the context of the application. CVSS score: 10.0. The maximum possible.
The Scanning Wave
Within 72 hours of public disclosure, mass scanning began. Threat intelligence feeds lit up with hundreds of thousands of probes per hour. Nation-state actors, ransomware groups, and opportunistic criminals all moved simultaneously. The Conti ransomware group had an internal chat log leaked months later showing them pivoting to Log4Shell exploitation within hours of the advisory.
Why Systems Remain Unpatched
The uncomfortable truth from assessments conducted months after the patch release: organisations did not know all the places Log4j existed in their environment. This is the software supply chain problem in its most concrete form. Log4j was not just in applications you deployed. It was bundled inside commercial products, embedded in vendor appliances, and nested inside fat JARs where no SBOM existed. Patch management assumes you know what you have. Many organisations discovered they did not.
Lessons for Defenders
Build a software bill of materials. Know every dependency in every application. Tools like Syft and Grype can scan container images and file systems for known vulnerable components.
Monitor outbound LDAP and RMI traffic. Even if you could not patch immediately, detecting the callback was possible. Most organisations had no visibility into outbound LDAP.
Assume compromise for exposed systems. If you ran an internet-facing Java application between December 9 and December 15, 2021 without WAF rules blocking the exploit string, assume it was probed and potentially compromised.
Conclusion
Log4Shell is a case study in why vulnerability management requires both asset inventory and network visibility, not just a patch deployment tool. The organisations that fared best were those who knew their attack surface before the advisory dropped.