Log4Shell had four fix versions. Here is why and which to run

Log4Shell, CVE-2021-44228, needed more than one fix because follow-on flaws were found after the first patch. The fixed releases were 2.15.0, 2.16.0, 2.17.0 and 2.17.1, each closing a different issue. If you must pick one today, choose the latest 2.x release you can adopt, and confirm against the Apache advisory.

The original flaw

Per Wikipedia, the flaw was privately reported to the Apache Software Foundation by Chen Zhaojun of Alibaba Cloud's security team on 24 November 2021. It was scored CVSS 10. Log4j 2 substitutes expressions of the form prefix colon name inside logged strings by default. A JNDI expression can direct it to an arbitrary LDAP or JNDI server, which can lead to execution of arbitrary Java code or to leaked information. Any application that logs user input with Log4j 2 was exposed.

The version sequence

• 2.15.0-rc1. Initial fix, released 6 December 2021. It restricted the servers and protocols allowed for lookups.
• 2.16.0. Fixes CVE-2021-45046, a related flaw, by disabling JNDI and message lookups.
• 2.17.0. Fixes CVE-2021-45105, a denial of service issue.
• 2.17.1. Fixes CVE-2021-44832, a harder to exploit remote code execution issue.

The infobox on that page lists 9 December 2021 as the patch date, so check the Apache pages if a precise date matters to you.

The workaround that failed

For earlier versions, the article advises removing the JndiLookup class from the classpath. Setting the option formatMsgNoLookups to true was an early recommendation, but it was later found not to prevent exploitation in all cases.

This is a useful reminder that a workaround is a stopgap. Record it as one, with a date to remove it.

What to do in your own estate

1. Find every copy of Log4j, including copies inside bundled or shaded jars. A scanner that reads manifests alone can miss them.
2. Compare the version you find with the sequence above.
3. Upgrade to the latest release your platform supports.
4. Re-scan, and keep the inventory so the next advisory takes minutes.

Lesson for incident response

The first patch is rarely the last. Plan for a second wave of advisories on the same component, and keep someone watching until the dust settles.

Questions to ask your vendors

If you buy software that bundles Java components, ask which version of Log4j each product contains and which fix level it reached. A vague answer such as a patch was applied is not enough. Ask for the version number and the date. Also ask how they find out about new advisories on bundled libraries. Vendors who keep an inventory can answer in a day. Vendors who cannot are telling you something about how they will handle the next one, so write that down when you review the relationship.

Quick check

Safeguard's SBOM and dependency scanning can find Log4j copies, including transitive ones, and a free scan is at gold.safeguard.sh/scan.

Sources

• Log4Shell

Last reviewed: 19 October 2026.