CVE-2021-45105

What it actually does

Apache Log4j 2 versions 2.0-alpha1 through 2.16.0, except 2.12.3 and 2.3.1, can enter uncontrolled recursive evaluation when logging crafted self-referential lookup patterns, especially where attacker-controlled data is placed into the Thread Context Map / MDC and then interpreted by a vulnerable logging pattern. The result is a denial of service condition, typically stack exhaustion or excessive CPU/memory consumption, causing the affected Java process to become unstable or crash. This issue does not provide remote code execution by itself and has no direct confidentiality or integrity impact, but availability impact can be high for exposed services that log attacker-influenced values.

Why it matters to the business

Successful exploitation can make affected applications unavailable, degrade service performance, trigger repeated restarts, and disrupt customer-facing or internal business workflows. Because Log4j is widely embedded in Java applications and libraries, exposure may exist indirectly through packaged applications, vendor software, or transitive dependencies. Although this issue is not in the CISA Known Exploited Vulnerabilities catalog and is not specifically associated with ransomware, the extremely high EPSS value indicates broad historical attacker interest in Log4j-related weaknesses and warrants prompt verification and remediation.

How an attack unfolds

An attacker first identifies an application using a vulnerable Log4j 2 release and determines whether attacker-controlled input is written into the Thread Context Map, Mapped Diagnostic Context, or another logging context that is expanded by Log4j lookups. The attacker then sends crafted input containing a recursive lookup expression, such as a value that references itself through context lookup syntax. When the application logs the value and Log4j evaluates the logging pattern, the lookup resolution repeatedly references itself. This uncontrolled recursion can exhaust stack, CPU, or memory resources, causing the process to throw errors, hang, crash, or restart. Exploitation requires a specific logging configuration and input path, so practical exploitability is more constrained than the earlier Log4j remote code execution issues, but internet-exposed services that log user-supplied headers, parameters, usernames, or request metadata remain important to review.

How to fix it

Upgrade Apache Log4j 2 to a fixed version: 2.17.0 or later for the main 2.x line, 2.12.3 for the Java 7-compatible branch, or 2.3.1 for the Java 6-compatible branch. Prefer upgrading to the latest currently supported Log4j release rather than only the minimum fixed version. Inventory both direct and transitive Log4j dependencies in application builds, container images, application servers, vendor products, and bundled JAR files. If immediate upgrade is not possible, reduce exposure by removing or avoiding logging patterns that perform context lookups on attacker-controlled Thread Context Map / MDC values, sanitizing untrusted input before it can enter logging context data, rate-limiting high-volume requests, and using WAF or gateway controls to block obvious Log4j lookup probes. Do not rely solely on removing JndiLookup, because this specific issue is recursive lookup denial of service rather than JNDI remote code execution.

How to confirm the fix worked

Confirm that no deployed artifact contains vulnerable Log4j 2 versions 2.0-alpha1 through 2.16.0, except fixed 2.12.3 and 2.3.1. Validate dependency manifests, SBOMs, build outputs, container layers, shaded or fat JARs, application server libraries, and vendor-supplied packages. For Java applications, inspect JAR metadata such as META-INF/MANIFEST.MF, Maven pom.properties files, Gradle dependency reports, and runtime classpaths for log4j-core versions. After patching, run a controlled non-production test using benign self-referential lookup-like input to confirm the application does not crash, recurse, or emit Log4j recursive evaluation errors. Monitor process stability, JVM error logs, application logs, and restart counts after deployment.

Typical attack path

1. Identify Java applications or packaged products that include Apache Log4j 2.0-alpha1 through 2.16.0, excluding already-fixed 2.12.3 and 2.3.1 releases.
2. Probe externally reachable input fields, HTTP headers, API parameters, authentication fields, or message payloads that are likely to be logged.
3. Submit self-referential lookup strings intended to be placed into the Thread Context Map / MDC or evaluated by Log4j lookup expansion.
4. Trigger application behavior that causes the crafted value to be logged.
5. Cause recursive lookup evaluation inside Log4j, leading to stack exhaustion, excessive resource use, process failure, or service restart.
6. Repeat requests to sustain a denial of service or create operational instability.

How to detect it

To determine whether exploitation was attempted or successful, review web access logs, API gateway logs, WAF logs, load balancer logs, application logs, JVM logs, container orchestration events, and process supervision logs. Look for Log4j lookup syntax in HTTP headers, query strings, form fields, JSON payloads, usernames, user-agent values, referer values, and other request metadata followed by application errors or restarts. For successful denial of service, correlate suspicious requests with StackOverflowError, OutOfMemoryError, excessive CPU use, repeated JVM crashes, container restarts, health-check failures, 5xx response spikes, or watchdog restarts. Because this issue requires recursive lookup evaluation rather than JNDI execution, searches should include ctx, date, lower, upper, main, env, sys, and nested lookup patterns, not only jndi strings. Also inspect Thread Context Map / MDC-related log patterns and application traces for recursive context resolution failures.

• ${ctx:
• ${ctx:loginId}
• ${ctx:apiversion}
• ${ctx:apiversion:-${ctx:apiversion}}
• ${${::-${::-$${::-j}}}}
• ${jndi:
• ${lower:
• ${upper:
• ${env:
• ${sys:
• ${main:
• java.lang.StackOverflowError
• java.lang.OutOfMemoryError
• ERROR StatusLogger
• Recursive evaluation
• Infinite loop in property interpolation
• org.apache.logging.log4j.core.lookup
• org.apache.logging.log4j.core.pattern.MessagePatternConverter
• org.apache.logging.log4j.core.impl.MutableLogEvent
• ThreadContext
• Mapped Diagnostic Context
• MDC
• log4j-core-2.0-alpha1.jar
• log4j-core-2.0.jar
• log4j-core-2.1.jar
• log4j-core-2.2.jar
• log4j-core-2.3.jar
• log4j-core-2.4.jar
• log4j-core-2.5.jar
• log4j-core-2.6.jar
• log4j-core-2.7.jar
• log4j-core-2.8.jar
• log4j-core-2.9.jar
• log4j-core-2.10.jar
• log4j-core-2.11.jar
• log4j-core-2.12.0.jar
• log4j-core-2.12.1.jar
• log4j-core-2.12.2.jar
• log4j-core-2.13.jar
• log4j-core-2.14.jar
• log4j-core-2.15.jar
• log4j-core-2.16.jar

What your security team should do

• Prioritize internet-facing Java applications, APIs, identity services, logging-heavy gateways, and business-critical services that use Log4j 2.
• Upgrade all Apache Log4j 2 deployments to 2.17.0 or later, or to 2.12.3 / 2.3.1 only where legacy Java compatibility requires those branches.
• Perform dependency and artifact scanning for embedded log4j-core JARs, including shaded JARs, containers, third-party applications, and vendor-managed software.
• Review logging configurations for context lookup usage involving attacker-influenced Thread Context Map / MDC data.
• Add temporary gateway, WAF, or reverse-proxy rules to rate-limit or block requests containing Log4j lookup syntax while remediation is underway.
• Search historical logs for recursive lookup strings, Log4j errors, JVM stack overflows, out-of-memory events, abnormal CPU spikes, and process restarts around suspicious request activity.
• Coordinate with application owners and vendors to confirm patched versions, redeploy affected services, and remove obsolete vulnerable libraries from images and build caches.