CVE-2021-44228 is a critical-severity (CVSS 10) Improper Input Validation vulnerability in org.apache.logging.log4j:log4j-core. 384 public exploit references exist, so weaponization risk is real. A fix is available for org.apache.logging.log4j:log4j-core — see the affected versions and patch details below.
Remote code injection in Log4j
Exploitation Status
Actively exploited in the wild
- CISA’s SSVC triage classifies this CVE as under active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2021-44228.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2021-44228 by exploitation likelihood (EPSS) against impact (CVSS). In the shaded patch-first corner (EPSS 50%+, CVSS 7.0+).
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the ≥ 90% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.apache.logging.log4j:log4j-core☕org.apache.logging.log4j:log4j-core☕org.apache.logging.log4j:log4j-core☕com.guicedee.services:log4j-core☕org.xbib.elasticsearch:log4j☕uk.co.nichesolutions.logging.log4j:log4j-core☕org.ops4j.pax.logging:pax-logging-log4j2☕org.ops4j.pax.logging:pax-logging-log4j2+2 moreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.
Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.
Impact
Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.
Affected versions
Any Log4J version prior to v2.15.0 is affected to this specific issue.
The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.
Security releases
Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3
Affected packages
Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.
Remediation Advice
Updated advice for version 2.16.0
The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.
Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.
Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.apache.logging.log4j:log4j-core | ≥ 2.13.0&&< 2.15.0 | 2.15.0org.apache.logging.log4j:log4j-core:2.15.0 |
| ☕Maven | org.apache.logging.log4j:log4j-core | ≥ 2.0-beta9&&< 2.3.1 | 2.3.1org.apache.logging.log4j:log4j-core:2.3.1 |
| ☕Maven | org.apache.logging.log4j:log4j-core | ≥ 2.4&&< 2.12.2 | 2.12.2org.apache.logging.log4j:log4j-core:2.12.2 |
| ☕Maven | com.guicedee.services:log4j-core | all versions | No fix |
| ☕Maven | org.xbib.elasticsearch:log4j | all versions | No fix |
| ☕Maven | uk.co.nichesolutions.logging.log4j:log4j-core | all versions | No fix |
Affected Products
log4japachexcodeapplesynchrobentleysynchro 4dbentleyadvanced malware protection virtual private cloud applianceciscoautomated subsea tuningciscoResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Apache Log4j 2 - Remote Code Execution (RCE)
by kozmer · Dec 14, 2021
Apache Log4j2 2.14.1 - Information Disclosure
by leonjza · Dec 14, 2021
AD Manager Plus 7122 - Remote Code Execution (RCE)
by Chan Nyein Wai · Apr 1, 2023
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.apache.logging.log4j:log4j-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.apache.logging.log4j:log4j-core to 2.15.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-44228 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
How to detect CVE-2021-44228
A community-maintained Nuclei template exists for this CVE. You can scan for it directly:
nuclei -id cve-2021-44228 -u https://target- Template
- Apache Log4j2 Remote Code Injection
- Severity
- critical
- Impact
- Successful exploitation of this vulnerability can lead to remote code execution, potentially compromising the affected system.
- Remediation
- Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
Template by ProjectDiscovery nuclei-templates (melbadry9, dhiyaneshDK, daffainfo), MIT licensed. View the full template. Scan only systems you are authorised to test.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This issue only affects log4j versions between 2.0 and 2.14.1. In order to exploit this flaw you need: - 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. In Red Hat OpenShift…
For Log4j versions >=2.10 set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true For Log4j versions >=2.7 and <=2.14.1 all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m For Log4j versions >=2.0-beta9 and <=2.10.0 remove the JndiLookup class from the classpath. For example: ``` zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ``` On OpenShift 4 and in OpenShift Logging, the above mitigation can be applied by following the steps in this article: https://access.redhat.com/solutions/6578421 On OpenShift 3.11, mitigation to the affected…Source: Red Hat security advisory for CVE-2021-44228 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| OpenShift Logging 5.0 | openshift-logging/elasticsearch6-rhel8:v5.0.10-1 | RHSA-2021:5137 |
| OpenShift Logging 5.1 | openshift-logging/elasticsearch6-rhel8:v6.8.1-67 | RHSA-2021:5128 |
| OpenShift Logging 5.2 | openshift-logging/elasticsearch6-rhel8:v6.8.1-66 | RHSA-2021:5127 |
| OpenShift Logging 5.3 | openshift-logging/elasticsearch6-rhel8:v6.8.1-65 | RHSA-2021:5129 |
| Red Hat AMQ Streams 1.6.5 | see advisory | RHSA-2021:5133 |
| Red Hat AMQ Streams 1.8.4 | log4j-core | RHSA-2021:5138 |
| Red Hat Data Grid 8.2.2 | log4j-core | RHSA-2021:5132 |
| Red Hat Fuse 7.10 | log4j-core | RHSA-2021:5134 |
Frequently Asked Questions
Is CVE-2021-44228 in your dependencies?
Find it across Maven, including transitive dependencies.