When responding to Log4Shell, the single most important fact about any host is the exact Log4j version it runs. That one number tells you whether it is exposed to CVE-2021-44228, whether the incomplete first fix still leaves it at risk under CVE-2021-45046, and whether you are clear of the denial-of-service follow-up CVE-2021-45105. This article is a defender's checklist for answering one question precisely: is my Log4j version vulnerable? It explains the version-to-CVE mapping, how to find your true version, and what counts as safe.
The fastest way to get an answer for a specific build is the Log4j version checker, which maps a version string to its known issues.
The Short Version-to-Status Map
For the core Log4Shell JNDI flaw, the boundaries are well defined. Use this as your quick reference, then verify specifics with the version checker:
- 2.0-beta9 through 2.14.1: vulnerable to CVE-2021-44228, the original critical CVSS 10.0 remote code execution flaw.
- 2.15.0: fixes the original flaw but is still affected by CVE-2021-45046 and the later CVE-2021-45105, so it is not a safe endpoint.
- 2.16.0: removes message lookups and JNDI by default but remains affected by the CVE-2021-45105 denial-of-service issue.
- 2.17.0: addresses CVE-2021-45105; later a separate JDBC Appender issue (CVE-2021-44832) led to 2.17.1 as the recommended release.
- 2.17.1 and later: the recommended fixed line for Java 8 and above.
- 2.12.4 and 2.3.2: backported fixes for Java 7 and Java 6 respectively.
The original Log4j 1.x is a separate, end-of-life project and is not affected by this JNDI lookup flaw, but it is unsupported and carries other risks, so it should not be treated as a remedy.
Why the Boundary at 2.14.1 Matters
The phrase that defenders should commit to memory is "2.0-beta9 through 2.14.1." Anything in that range running with default settings is exposed to the full remote code execution scenario described in what is Log4Shell. If a host reports a version anywhere inside that band, treat it as critical and prioritise it for the remediation steps in the patching guide.
Finding Your True Version
The hard part is rarely the mapping; it is discovering which version you actually run. Log4j is usually a dependency of a dependency, bundled deep inside applications and vendor products. A clean checklist to find it:
- Search the filesystem. Look for
log4j-coreJAR files; the version is typically in the filename, for examplelog4j-core-2.14.1.jar. Be aware that a filename is not proof on its own, because some packaging renames or repackages the JAR; when the name has been changed, fall back to the manifest and embedded build properties to read the true version. - Inspect fat JARs and WARs. Log4j is frequently shaded or nested inside application archives, so look inside packaged artifacts, not just the top level.
- Check the manifest. The JAR's manifest and embedded pom properties record the implementation version when the filename has been changed.
- Query your build tooling. A dependency tree from your build system reveals transitive Log4j versions and which component pulls them in.
- Confirm with the checker. Feed the discovered version into the version checker to map it to its CVEs.
Do Not Forget Bundled and Vendor Software
Plenty of vulnerable Log4j lived inside appliances, agents, and commercial products where you cannot simply swap the JAR. For these, your version number comes from the vendor's advisory, not your own filesystem. Maintain a list of every product that might embed Java, check each vendor's Log4Shell advisory for the affected and fixed releases, and apply their updates. Scanning helps you spot the behaviour even when you cannot read the version directly; run the Log4Shell scanner against such systems to confirm exposure.
When a Version Looks Safe but Is Not
A few traps catch defenders. First, multiple copies: a host can carry several Log4j JARs at different versions, and the safe-looking one in your app server does not protect a vulnerable one bundled in a plugin. Second, the incomplete-fix problem: 2.15.0 is newer than the vulnerable range but is still affected by CVE-2021-45046, so "newer than 2.14.1" is not the same as "safe." The distinction between those follow-on CVEs is explained in CVE-2021-45046 vs 45105. Third, configuration drift: a host you patched can regress if a redeploy reintroduces an old artifact, so re-verify after changes. A useful habit is to treat any deploy, restore, or image rebuild as an event that invalidates your previous version assessment for that host, prompting a quick re-check rather than assuming the earlier result still holds.
What Counts as Safe Today
For a definitive answer, treat the following as your target state:
- Java 8 and above: Log4j 2.17.1 or later.
- Java 7: the 2.12.4 backport.
- Java 6: the 2.3.2 backport.
Anything below these, even if it is past the original 2.14.1 boundary, still has at least one open issue and should be moved up. The full sequence of releases and what each one fixed is laid out in the Log4j patch timeline.
Turning the Answer Into Action
Once you know a version is vulnerable, the response is not just to note it but to drive it to closure. Record the host, the component that bundles Log4j, the current version, and the target version. Prioritise internet-facing and high-value systems first, because those are the ones being actively probed. Then upgrade or apply the appropriate stopgap, and re-check with the version checker to confirm the new version really is in the safe range. Pair this with the log-hunting steps in detecting Log4Shell in logs so you also learn whether the host was probed before you closed the gap.
Recording Versions for the Whole Estate
On a single server the version question is quick, but across an estate it becomes a data-management task. The most effective defenders maintain a living record that lists, for every host, the component that bundles Log4j, the discovered version, the CVEs that apply, the exposure tier, and the target version. This record is what turns a scattered collection of findings into a plan you can actually drive to completion. It also makes reporting honest: instead of vague reassurance, you can state precisely how many hosts remain on a vulnerable version and how quickly that number is falling. Because versions can regress when software is redeployed, the record should be refreshed by periodic re-checks rather than captured once and trusted forever.
Keeping the Record Trustworthy
A version record is only as good as its freshness. Schedule recurring checks so that a host which regressed after a redeploy is caught quickly, and reconcile the record against actual scan results rather than against assumptions. When the two disagree, trust the live evidence and investigate the gap, because a stale record gives false confidence that is worse than no record at all. Treat the version record as living infrastructure rather than a one-time spreadsheet: tie it to your scanning cadence, reconcile it against live findings, and flag any host whose recorded version has not been re-confirmed recently. That discipline keeps the estate-wide picture accurate as software is redeployed, restored, and rebuilt over time, and it gives leadership an honest, current view of how much vulnerable Log4j genuinely remains across the organisation.
Conclusion
Whether your Log4j is vulnerable comes down to the version: 2.0-beta9 through 2.14.1 is exposed to the critical flaw, 2.15.0 and 2.16.0 still carry follow-on issues, and only 2.17.1 or the 2.12.4 and 2.3.2 backports are safe endpoints. Find your true version including transitive and bundled copies, then confirm each one with the version checker at log4shell.tools.