Log4Shell — the single most impactful CVE of the decade
CVE-2021-44228: A remote code execution in Log4j's JNDI lookup allowed attackers to execute arbitrary code by logging a crafted string. The library was transitively used by millions of Java apps; the disclosure triggered the largest coordinated emergency response in AppSec history.
What happened
A logging library included a feature that performed JNDI lookups on strings being logged. An attacker who could cause any user-controlled string to be logged (a User-Agent header, a username, a chat message) could trigger a JNDI lookup to an attacker-controlled LDAP server, which returned an arbitrary Java class for the victim to execute.
Timeline
JNDI lookup feature added to Log4j.
Alibaba discloses privately to Apache.
Exploit published publicly on Twitter; mass exploitation begins within hours.
CVE-2021-44228 assigned; CVSS 10.0.
Industry-wide patching effort; variants CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 follow.
Root cause
A logging library — the most transitively-depended-on type of library in existence — shipped with a feature that executed arbitrary remote code on untrusted input. The feature was obscure; most users did not know it existed.
Impact
- Estimated 3+ billion affected devices globally
- Sustained mass-exploitation for weeks
- Industry-wide reckoning with transitive-dependency risk
Once public (December 9, 2021): yes, within 15 minutes of disclosure, via Securie's real-time CVE-to-block pipeline. Pre-disclosure: the code pattern (dynamic class loading from string) is detectable but rarely flagged — this was an education-level finding that no tool prioritized.
Lessons
- Transitive dependencies are first-class security surface
- Disable dynamic class loading in logging by default
- Every app needs to know its dependency tree, not just direct deps
- SBOM + SCA are table stakes