How Deep Is the Log4j Vulnerability in Maven Central? An In‑Depth Dependency Analysis

Security researchers from the Google Open Source Insights team investigated every version of every package in Maven Central to understand the impact of the recent Log4j vulnerability on the JVM ecosystem and to track mitigation efforts.

As of December 16, 2021, 35,863 available Maven Central packages depended on vulnerable Log4j code, meaning more than 8% of packages have at least one vulnerable version (excluding directly distributed binaries).

This 8% figure is strikingly high compared to the Maven Central ecosystem’s average impact of 2% and a median below 0.1%.

Most affected packages are indirect (transitive) dependencies, meaning they do not declare Log4j directly but inherit it through other libraries.

The JVM ecosystem finds remediation exceptionally difficult; at the time of writing, only about five thousand vulnerable packages had been fixed, leaving more than thirty thousand still exposed.

Depth matters: the deeper the vulnerability lies in the dependency chain, the more steps are required to remediate. Over 80% of affected packages have the vulnerability appearing beyond the first level, with many descending five or more levels, some even nine, necessitating fixes starting from the deepest dependencies.

Another challenge stems from the resolution algorithm and ecosystem conventions. In Java, developers typically specify “soft” version requirements, assuming no other version of the same artifact appears in the graph; the resolver then selects the explicitly declared version. Fixing such issues often requires maintainers to take explicit actions to update dependency constraints to patched versions, contrasting with ecosystems like npm where open version ranges let the resolver automatically pick the latest safe release.

Overall, assessing the total time needed for ecosystem‑wide remediation remains difficult; among all publicly disclosed vulnerable Maven packages, fewer than half (48%) have been fixed.