Log4Shell Two Years Later: Why Enterprise Java Stacks Are Still Exposed
The Patch That Wasn't Enough
When CVE-2021-44228 dropped in December 2021, incident-response teams around the world scrambled to upgrade Log4j. Most declared victory within a week. Two years on, our scanning data at OSSeva tells a different story: a significant fraction of enterprise Java workloads still contain at least one artifact that bundles a vulnerable Log4j version — not because engineering teams ignored the advisory, but because the dependency is nested three or four levels deep inside a vendor-supplied JAR or a legacy internal library no one remembers shipping.
Why Transitive Dependencies Hide in Plain Sight
Maven and Gradle dependency trees are deceptively incomplete. A direct dependency on spring-boot-starter-web:2.7.x pulls in dozens of transitive artifacts, and each of those artifacts may itself bundle — not merely declare — Log4j via shading or fat-JAR repackaging. Standard SCA tooling that only inspects declared coordinates misses shaded copies entirely.
- Shaded JARs: Vendors frequently repackage upstream libraries under their own namespace to avoid classpath conflicts, stripping the original artifact metadata that scanners rely on.
- Nested archives: WAR and EAR files can contain JAR files that themselves contain JAR files. Recursive archive unpacking is computationally expensive and often skipped.
- SBOM gaps: Even teams that generate SBOMs at build time rarely re-scan the compiled output to verify that the SBOM matches what actually landed on disk.
CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105
The original Log4Shell advisory was followed in quick succession by two additional CVEs. CVE-2021-45046 demonstrated that the initial 2.15.0 fix was incomplete under certain non-default configurations, and CVE-2021-45105 introduced a denial-of-service vector in the lookup mechanism. Teams that patched to 2.15.0 and stopped are still partially exposed. The safe floor for Log4j 2.x is 2.17.1 for Java 8 environments and 2.17.0 for Java 11+, with 2.19.0 or later strongly preferred for its additional hardening.
A Practical Detection Checklist
- Run a recursive JAR scanner — not just a dependency-tree check — against every deployable artifact, including WARs and EARs.
- Search for
JndiLookup.classby SHA-256 hash, independent of the enclosing artifact's declared version. - Audit vendor-supplied bundles separately; treat them as opaque binaries until the vendor provides a verified SBOM.
- Automate re-scanning on every build so that a dependency upgrade by a transitive owner triggers a new check downstream.
Where OSSeva Fits In
OSSeva's Assure service provides continuous scanning of your artifact repositories and build pipelines, surfacing transitive Log4j exposures alongside remediation guidance that accounts for your specific Java version and deployment target. Rather than a point-in-time audit, you get a live signal that updates whenever a new build is published or a new vulnerability advisory is issued against any component in your dependency graph.
Conclusion
Log4Shell is not a solved problem for enterprise Java. Sustainable remediation means going beyond the direct dependency list, automating recursive scanning of compiled artifacts, and maintaining a living SBOM that is re-validated on every release. The organizations still finding vulnerable Log4j instances in 2025 are not negligent — they are discovering the hard way that the software supply chain is deeper than any single tool was initially built to map.
Tags