CVE-2021-45105: Apache Log4j DoS Vulnerability

CVE-2021-45105 Overview

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) contain a vulnerability that fails to protect against uncontrolled recursion from self-referential lookups. This flaw allows an attacker with control over Thread Context Map (MDC) data to cause a denial of service when a specially crafted string is interpreted by the logging framework. This vulnerability is part of the broader Log4Shell vulnerability series that impacted organizations globally during December 2021.

Critical Impact
Attackers can crash Java applications using vulnerable Log4j2 versions by injecting self-referential lookup strings, causing stack overflow through infinite recursion and resulting in application denial of service.

Affected Products

Apache Log4j 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1)
Oracle WebLogic Server 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0
Oracle Communications products (multiple versions including Diameter Signaling Router, Session Route Manager, and others)
Oracle Enterprise Manager Base Platform 13.4.0.0 and 13.5.0.0
Oracle PeopleSoft Enterprise PeopleTools 8.58 and 8.59
NetApp Cloud Manager
Debian Linux 10.0 and 11.0
SonicWall Email Security, Network Security Manager, and Web Application Firewall

Discovery Timeline

2021-12-18 - CVE-2021-45105 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-45105

Vulnerability Analysis

This vulnerability stems from improper input validation (CWE-20) in Apache Log4j2's lookup functionality. The logging framework provides powerful string substitution capabilities through lookups, which allow dynamic content to be resolved at runtime. When processing log messages containing lookup patterns like ${ctx:key}, Log4j2 resolves these references by examining the Thread Context Map.

The vulnerability manifests when an attacker can influence the Thread Context Map data with values containing self-referential lookups. When Log4j2 attempts to process such a lookup, it enters an infinite recursion loop as each lookup resolution triggers another lookup resolution, eventually exhausting the stack and causing the application to crash with a StackOverflowError.

While this vulnerability requires high attack complexity due to the need to control Thread Context Map data, it can be exploited over the network without authentication or user interaction, making it a significant concern for internet-facing applications.

Root Cause

The root cause is the lack of recursion depth protection in Log4j2's lookup resolution mechanism. When evaluating string interpolation patterns in log messages, the StrSubstitutor class did not implement safeguards against circular references or self-referential lookup chains. This allows malicious input to create infinite recursion scenarios.

The vulnerability specifically affects how Log4j2 handles context lookups (${ctx:...}), where an attacker can set a context value that references itself or creates a lookup chain that ultimately loops back, triggering unbounded recursion.

Attack Vector

The attack requires an attacker to have some level of control over data that gets placed into the Thread Context Map (also known as MDC - Mapped Diagnostic Context). This is commonly achieved through:

HTTP request headers that applications log (e.g., User-Agent, X-Forwarded-For)
User-supplied input fields that are logged for diagnostic purposes
Query parameters or form data that enters the logging pipeline
Authentication tokens or session identifiers included in log messages

When the application logs a message that triggers the self-referential lookup resolution, the Java process experiences a stack overflow and crashes. The attack can be repeated to maintain a persistent denial of service condition against the target application.

The exploitation pattern involves injecting a payload such as ${${ctx:key}} where the context key key is set to a value that creates infinite recursion. This causes the lookup resolver to repeatedly attempt resolution until the JVM stack is exhausted.

Detection Methods for CVE-2021-45105

Indicators of Compromise

Unexpected application crashes with java.lang.StackOverflowError in Log4j2-related stack traces
Repetitive application restarts due to JVM crashes in logging components
Log entries containing nested lookup patterns like ${ctx:${ctx:...}} or similar recursive structures
HTTP requests with suspicious recursive patterns in headers or parameters that are subsequently logged

Detection Strategies

Monitor Java applications for frequent StackOverflowError exceptions originating from org.apache.logging.log4j classes
Implement web application firewall rules to detect and block requests containing nested ${...} patterns in headers and parameters
Scan application dependencies to identify Log4j2 versions between 2.0-alpha1 and 2.16.0 using software composition analysis tools
Review application logs for evidence of lookup recursion attempts or malformed context variable references

Monitoring Recommendations

Configure JVM monitoring to alert on repeated StackOverflowError exceptions within short time windows
Enable detailed access logging to capture HTTP request headers and parameters for forensic analysis
Implement application performance monitoring to detect abnormal restart patterns indicating DoS attacks
Set up dependency scanning in CI/CD pipelines to flag vulnerable Log4j2 versions before deployment

How to Mitigate CVE-2021-45105

Immediate Actions Required

Upgrade Apache Log4j2 to version 2.17.0 or later for Java 8+, version 2.12.3 for Java 7, or version 2.3.1 for Java 6
If immediate upgrade is not possible, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Review all applications in your environment for Log4j2 usage, including transitive dependencies
Implement input validation to sanitize user-controlled data before it enters the Thread Context Map

Patch Information

Apache addressed this vulnerability in Log4j 2.17.0 (for Java 8+), 2.12.3 (for Java 7), and 2.3.1 (for Java 6). The fix implements recursion depth limits in the lookup substitution logic to prevent infinite loops. Organizations should consult vendor-specific advisories for downstream products:

Workarounds

In Log4j 2.10 or later, set the system property log4j2.formatMsgNoLookups=true to disable message lookup substitution
Set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true as an alternative to the system property
Modify the logging configuration to use %m{nolookups} pattern instead of %m in PatternLayout configurations
Implement network-level filtering to block requests containing recursive lookup patterns before they reach vulnerable applications

bash

# Configuration example
# Set JVM system property to disable lookups
java -Dlog4j2.formatMsgNoLookups=true -jar your-application.jar

# Or set environment variable
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

# Remove JndiLookup class from existing jar (mitigation for older versions)
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class