Log4Shell (CVE-2021-44228): the Log4j JNDI lookup flaw

02Affected and fixed versions, including the follow-ups

The original fix was incomplete, and three more CVEs followed within three weeks as researchers probed the patches. This is normal for a high-profile flaw — the React Server Components and Redis Lua advisories later followed the same pattern — so "Log4Shell is patched" was never the same as "this version is safe." The clean target is 2.17.1 (or 2.12.4 / 2.3.2 for older Java).

03How an attack worked, conceptually

The attacker placed a JNDI lookup expression in any value that would be logged. When Log4j rendered the log line, it resolved the lookup, reached out to the attacker's directory server, and — on affected Java runtimes — fetched and instantiated a remote object, which ran the attacker's code. On its own, a lookup could also cause the server to make an outbound DNS or LDAP request, which attackers used as a quick, low-noise way to confirm a target was vulnerable.

Even where the direct code-load path was blocked by a modern Java runtime, the lookups could still read local data such as environment variables and smuggle it out through the hostname of the outbound request. That is why upgrading the JDK was never a complete fix — the only real remedy was to remove the dangerous behaviour from Log4j itself.

04How to find vulnerable Log4j

The hard part of Log4Shell was never the patch; it was finding every copy. Log4j is often bundled deep inside other jars, wars and ears — shaded, repackaged, three dependencies down — so a simple package query misses most of it. Search the filesystem for the JndiLookup class and for log4j-core jars, looking inside archives, not just at their names.

# Find archives that contain the vulnerable class or a log4j-core jar
find / -xdev -type f \( -name '*.jar' -o -name '*.war' -o -name '*.ear' \) 2>/dev/null |
while IFS= read -r f; do
  python3 -m zipfile -l "$f" 2>/dev/null |
    grep -qE 'org/apache/logging/log4j/core/lookup/JndiLookup\.class|log4j-core-[0-9][^/ ]*\.jar' &&
    echo "$f"
done

# Read the exact version from a jar's embedded metadata
python3 -c 'import sys,zipfile; print(zipfile.ZipFile(sys.argv[1]).read(
  "META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties").decode())' log4j-core-*.jar

05How to fix and mitigate it

Upgrade log4j-core to 2.17.1 (Java 8+), 2.12.4 (Java 7) or 2.3.2 (Java 6). If you cannot upgrade immediately, the supported stopgap is to physically remove the JndiLookup class from the jar — this is the mitigation Apache endorsed, unlike the formatMsgNoLookups flag, which Apache later marked insufficient because other code paths could still reach the lookups.

• Upgrade log4j-core to a fully fixed release — 2.17.1, 2.12.4 or 2.3.2 — rather than stopping at 2.15.0
• If you cannot upgrade, delete the JndiLookup class from every copy and restart the app
• Do not rely on the formatMsgNoLookups flag alone; Apache classed it as insufficient
• Upgrading the JDK blocks the remote class-load path but not data exfiltration via lookups, so it is not a substitute for patching Log4j

# Only when you cannot upgrade yet; prefer upgrading to 2.17.1 / 2.12.4 / 2.3.2.
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

# Then restart the application so the modified jar is reloaded.

06Why WAF rules were a stopgap, not a cure

In the first hours, a web application firewall rule that blocked the obvious JNDI string genuinely bought time, and buying time mattered when the alternative was nothing. But attackers quickly obfuscated the expression using Log4j's own lookup grammar — lowercasing fragments, nesting lookups, splitting keywords — so that a blocked literal could be reconstructed by the logger after it passed the filter. Cloudflare reported attackers moving from plain ${jndi: strings to evasive forms within days. Broader rules, such as flagging any ${ in input, catch more variants but also legitimate input.

Be honest about what this means. A reverse proxy can reduce exploitation attempts, slow mass scanning and give you breathing room, and a proxy such as GuardX can absorb the flood of opportunistic probes that follows a disclosure. It cannot reliably stop a determined attacker against an unpatched server, because the vulnerable behaviour is inside your application and the input space is enormous. Edge filtering is a seatbelt, not an airbag: use it while you patch, not instead of patching. Virtual patching explains why syntax the application expands later is the hardest case for any rule.

07A long tail of exploitation

The Cyber Safety Review Board concluded that vulnerable instances of Log4j "will remain in systems for many years to come, perhaps a decade or longer," and CVE-2021-44228 was still on CISA's list of the top routinely exploited vulnerabilities of 2023. CVE-2021-45046 was added to the KEV catalogue in May 2023. The lesson for operators is that disclosure is the start, not the end: keep an inventory of what you run, keep protection always on rather than switched on during incidents, and expect scanning for old flaws to continue indefinitely.