CVE-2021-45046 in Log4j
Summary
by MITRE • 12/14/2021
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the 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) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/27/2025
The vulnerability described in CVE-2021-45046 represents a critical security flaw in Apache Log4j 2 that emerged as an incomplete remediation to the widely publicized CVE-2021-44228, commonly known as Log4Shell. This vulnerability specifically targets the flawed mitigation implemented in Apache Log4j 2.15.0, which was intended to address the remote code execution vulnerability but proved insufficient in certain non-default configurations. The flaw resides in the logging framework's handling of Thread Context Map (MDC) input data, creating a persistent security gap that attackers can exploit to execute malicious code within affected systems. The vulnerability operates through a sophisticated attack vector that leverages the logging system's pattern layout functionality to bypass the original security measures.
The technical implementation of this vulnerability stems from the incomplete nature of the patch applied in version 2.15.0, which failed to adequately address all possible attack scenarios involving non-default logging configurations. When logging configurations utilize specific Pattern Layout elements such as Context Lookup patterns with $${ctx:loginId} syntax or Thread Context Map patterns like %X, %mdc, or %MDC, the system becomes vulnerable to malicious input manipulation. Attackers can craft specially designed input data that contains JNDI Lookup patterns, effectively exploiting the logging framework's ability to resolve external references. This exploitation mechanism creates a pathway for information disclosure and remote code execution in environments where the vulnerable configurations are present, while local code execution becomes possible in all affected environments regardless of network exposure. The vulnerability operates at the intersection of logging configuration management and external reference resolution, making it particularly insidious as it leverages legitimate system functionality for malicious purposes.
The operational impact of CVE-2021-45046 extends beyond simple remote code execution, creating a comprehensive attack surface that can lead to complete system compromise across multiple environments. Organizations running Apache Log4j 2.15.0 with specific logging configurations face potential data breaches, system infiltration, and unauthorized access to sensitive information. The vulnerability's persistence across different deployment scenarios means that even systems that were previously considered secure may suddenly become vulnerable when certain logging patterns are introduced. This characteristic aligns with ATT&CK technique T1059.007 for command and scripting interpreter and CWE-94 for external control of code generation, as attackers can manipulate the logging framework to execute arbitrary code. The information leak component of this vulnerability can expose sensitive data stored in thread context maps, potentially compromising user credentials, session information, and other confidential data processed through the affected logging system.
The remediation approach implemented in Log4j 2.16.0 and 2.12.2 addresses the vulnerability through a multi-layered defensive strategy that fundamentally changes how the logging framework handles message patterns and JNDI functionality. The solution involves completely removing support for message lookup patterns that could be exploited and disabling JNDI functionality by default, effectively closing the attack vector that enabled the vulnerability. This approach follows security best practices by implementing defense in depth through configuration hardening and by reducing the attack surface through default security settings. Organizations should implement these updates immediately and conduct thorough configuration reviews to ensure that no legacy logging patterns remain that could potentially reintroduce similar vulnerabilities. The fix demonstrates the importance of comprehensive vulnerability remediation and proper security testing of patches, as the initial mitigation in version 2.15.0 failed to account for all possible exploitation scenarios. This vulnerability serves as a critical reminder of the complexity involved in securing logging frameworks and the necessity of thorough validation of security patches in enterprise environments.