On Friday, the news broke about Log4Shell, an easy-to-exploit vulnerability being exploited across the world. We have kept our blog up to date with the latest news, mitigations and strategies that you can take as a maintainer or operator of software using Log4j.
The news is big enough to have been featured in the media, and the crunch has been felt by industry insiders - but there are a few unanswered questions. Why exactly is this so widespread?
Sonatype are the stewards of the default location for most Java software to fetch their components: the Maven Central Repository. It's also the go-to-destination for producers of open source to distribute their products. As such, we have been diving into download statistics to see how quickly the transition from vulnerable to fixed versions is happening.
Firstly, how popular is Log4j exactly?
When looking at download statistics for the affected coordinates at org.apache.logging.log4j :log4j-core over a period of the last 4 months, we observe 28.6 million downloads to date.
log4j-core is the top 252nd most popular component by download volume in Central out of 7.1 million total artifacts in November 2021 - and that's just the vulnerable versions.
Log4j 2.x is in the top 0.003% percentile in popularity by downloads out of a total population of 7.1 million.
In short - it's as popular as components get.
All versions taken into account in the aggregate, Log4j ranks as one of the most popular components across the total population.
Log4j is seen as a dependency in almost 7,000 other open source projects - it's such a common piece of code that it's even a building block in the Ingenuity helicopter aboard the Mars rover.
Apache Twitter post from June, 2021
Additionally, we've seen the code that was implicated with this vulnerability in JndiManager.class was borrowed by 783 other projects, being seen in over 19,562 individual components.
This occurs because open source code is designed to be borrowed and reused. This secondary expansion suggests there is further investigation to be had on these other projects and whether they are affected by a similar vulnerability.
When looking at the relative popularity of the log4j-core component, the most popular version adopted by the community was 2.11.2, released in February 2019, followed by log4j-core 2.14.1.
Figure: Relative popularity of log4j-core versions
How fast has the patched version been adopted?
Arguably the most important question to ask is how fast are we replacing the vulnerable versions in our builds with fixed ones? Version 2.15.0-rc2 which fixed the patch was pushed out to maven central under the 2.15.0 version number on December 10 2021 00:26 UTC.
Up to the time of writing Monday, December 13, 2021, since the release, we have seen a massive increase in the download volume of this new version. Today, there have been over 633,000 downloads of log4j-core:2.15.0 from its initial release, with volume growing steadily.
However, we are still seeing tremendous usage of the vulnerable versions. On aggregate, 65% of the current downloads for log4j-core come from vulnerable versions.
This is aligned with the historical patterns we've observed for other high profile fixes. For example, today struts2-rest-api which was the plugin that caused the famous breaches at Equifax and dozens of other companies still sees wide ranging traffic to vulnerable versions.
When this incident happened, download volumes initially dipped but quickly returned to their steady state.
Historical look at the download popularity of the vulnerable Struts framework from our 2019 State of the Software Supply Chain Report
This suggests that we have a long tail of dealing with the effects of this vulnerability ahead of us. In both historical cases malicious attacks were observed soon after the vulnerability came out - and the first reported breaches soon followed.
Even today, 37% of downloads for struts2 are still for vulnerable versions.
How are people upgrading it?
Looking at upgrade paths we see customer's development teams take, this luckily is an easy upgrade process. The most common good migration path based on the eight rules of migration we set out in the 2021 State of the Software Supply Chain report is to go straight to the latest, but we also observe several stepped migrations.
It's not beyond the realm of speculation to assume that with log4j2, some of those breaches have already happened with first reports of affected companies starting to come out in media.
Again, when contrasting with historical incidents, in the case of the struts2 vulnerability of 2017 the exploit window was down to 3 days. In the case of Log4j - malicious traffic reportedly began almost immediately.
We remain committed to helping the world stay informed as the situation evolves. The Log4j project has since released 2.16.0 and 2.17.0 - giving the world two possible versions to upgrade to.
ADDENDUM - Sat 18th Dec: We have published a near-real time Log4j Information Center. Visit it for the latest statistics on how the world is remediating Log4Shell.
Find out more what Sonatype customers can do.
