CVE-2021-45046
log4j-core: DoS in log4j 2.x with thread context message pattern and context lookup pattern (incomplete fix for CVE-2021-44228)
Severity
ModerateRed Hat Product Security
CVSS 3.1
Review impact separately from score.
Published · December 14, 2021
Updated · November 5, 2026
Description
A flaw was found in the Apache Log4j logging library in versions from 2.0.0 and before 2.16.0. A remote attacker with control over Thread Context Map (MDC) input data could craft malicious input using a JNDI Lookup pattern resulting in remote code execution (RCE) in a limited number of environments.
Statement
Although we have matched Apache's CVSS score, with the exception of the scope metric which will remain unaltered at "unchanged"; as we believe code execution would be at the permission levels of the running JVM and not exceeding that of the original CVE-2021-44228 flaw.
We have given this vulnerability an impact rating of Moderate, this is because of the unlikely nature of log4j lookup mapping values being derived from attacker controlled values. This is not the default configuration for end-applications using log4j 2.x and would require explicit action from a privileged user (a developer or administrator) to access the vulnerability. In certain non-default configurations, it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was insufficient.
This issue affects the log4j version between 2.0 and 2.15. Log4j 1.x is NOT impacted by this vulnerability.
Prerequisites to exploit this flaw are :
- A remotely accessible endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send arbitrary data,
- A log statement in the endpoint that logs the attacker controlled data.
- Log4j configuration file should be explicitly configured to use a non-default Pattern Layout with a Context Lookup eg. ($${ctx:loginId})
In most cases, the mitigation suggested for CVE-2021-44228 (i.e. to set the system property log4j2.noFormatMsgLookup to `true) does NOT mitigate this specific vulnerability.
Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
For Elasticsearch, as shipped in OpenShift 3.11, the "log4j2.formatMsgNoLookups=true" system property mitigation is sufficient as there are no included non-standard configurations that allow for exploitation:
https://github.com/openshift/openshift-ansible/blob/release-3.11/roles/openshift_logging_elasticsearch/templates/log4j2.properties.j2
https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476
For CodeReady Studio the fix for this flaw is available on CodeReady Studio 12.21.3 and above versions.
CVSS score applicability
The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.
Mitigation
For Log4j versions up to and including 2.15.0, this issue can be mitigated by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
CVSS / CWE
CVSS 3.1 · 8.1CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-917 · Improper Neutralization of Special Elements used in an Expression Language Statement