Log4Shell Three Years Later: Why Unpatched Dependencies Still Dominate Enterprise Risk

Log4Shell Is Still Being Exploited

CISA's Known Exploited Vulnerabilities (KEV) catalog still lists CVE-2021-44228. Shodan and Censys scans continue to find vulnerable Log4j instances exposed to the internet. Three years after disclosure, a CVSS 10.0 RCE vulnerability is still present in production systems.

This is not a failure of awareness. Security teams know about Log4Shell. The failure is operational: organizations that know they use Log4j cannot reliably find all the places they use it.

Why Dependency Graph Blindness Persists

The Transitive Dependency Problem

Log4j is not a direct dependency for most affected applications. It's a transitive dependency. A dependency of a dependency of a dependency. The typical discovery path during the Log4Shell incident was:

1. Application uses Elasticsearch client
2. Elasticsearch client depends on Apache Kafka connector
3. Kafka connector bundles Log4j

No developer ever typed log4j into their build file. The dependency arrived through the transitive graph, invisible to anyone not running a full dependency audit.

Shading and Repackaging

Some Log4j exposure was discovered not through declared dependencies but through shaded JARs. Redistributable packages that bundle their dependencies and rename them to avoid conflicts. A shaded JAR containing Log4j doesn't appear as a Log4j dependency in pom.xml; it appears as the outer package with Log4j code hidden inside.

Binary composition analysis (examining JAR contents rather than declared dependencies) is required to detect shaded vulnerabilities. Manifest-based scanning misses them entirely.

The "We Patched It" Problem

Organizations that patched Log4j in their direct dependencies and forgot to update packages that bundle Log4j transitively are effectively still vulnerable. The patch is not complete unless the transitive graph is clean.

The CVE-2021-44228 Exploitation Timeline

The vulnerability was disclosed December 9, 2021. Active exploitation was observed within hours. The patch (2.15.0) was itself found to be insufficient; 2.16.0, 2.17.0, and subsequent releases addressed multiple bypass variants.

Organizations following the "patch the known CVE" model had to apply multiple patches to reach a fully remediated state, while attackers were actively scanning for the vulnerability between each release.

Current Exploitation Context

In 2025-2026, Log4Shell exploitation is concentrated in two categories:

1. Opportunistic scanning hitting forgotten internal systems (staging, legacy apps, utility services)
2. Targeted attacks where Log4Shell provides initial access to enterprise environments where the attacker already has reconnaissance data

The vulnerability is no longer a zero-day. It's inventory debt. Systems running vulnerable Log4j versions are in organizations that don't know they're running it.

How Deva Addresses Dependency Risk

Deva's dependency graph scanner traverses the full transitive graph, not just declared dependencies. It identifies packages-within-packages (shaded JARs for Java, bundled dependencies in wheel files for Python) and matches all discovered components against 27K CVEs.

For Log4j specifically, the scanner checks for all three CVE variants (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105) and their mitigated ranges, including cases where Log4j is present but the JNDI feature is disabled in configuration. For a deeper look at developer-environment supply chain risk, see the XZ Utils analysis and OWASP's A03:2025 Software Supply Chain Failures.