• Home
  • Resources
  • Blog
  • Research Shows Over 100,000 Libraries Affected By Maven Vulnerability CVE-2021-26291

Research Shows Over 100,000 Libraries Affected By Maven Vulnerability CVE-2021-26291

Libraries Affected By Maven Vulnerability CVE-2021-26291
Libraries Affected By Maven Vulnerability CVE-2021-26291

By Jonathan Leitschuh; Daniel Elkabes, Senior Security Researcher at WhiteSource; Ofir Keinan, Software Developer at WhiteSource

The latest Maven release 3.8.1 contains a fix to security vulnerability CVE-2021-26291. Detected and reported by security researcher Jonathan Leitschuh, the vulnerability affects over 100,000 libraries in Maven Central, according to the WhiteSource security research and knowledge teams. 

Jonathan Leitschuh followed up on a POC conducted by Cédric Champeau about a Maven cross repository injection vulnerability (XRI).

The vulnerability, which was published with a fix already available, could result in a man-in-the-middle (MitM) attack due to POMs in Maven Central with custom repositories that refer to a URL over HTTP, rather than HTTPS. 

One of the many configurations in pom.xml files is a list of dependencies that need to be resolved. Maven handles them in the following order: 

  1. Checking our settings.xml files (Global and User) for any system and/or user configuration.
  2. Checking if the package exists in the local repository — a directory on the machine running Maven.
  3. If the package is still not found, the next default is to check in the Maven Central Repository.
  4. If Maven Central isn’t available the next place to check will be an internal or external repository that can be reached and downloaded using HTTP. This includes any of the maintainers’ private resources, like their own servers or machine — herein lies the problem. 

Jonathan had previously performed research in this area and found that thousands of Gradle- and Maven-based OSS projects were relying upon HTTP instead of HTTPS to resolve their dependencies.

The Risk

Using HTTP instead of HTTPS could potentially lead to a man-in-the-middle attack. A MitM attack occurs when attackers insert themselves into users’ networks. A MitM attacker would then exploit insecure connections to access users’ private information and tamper with it. For example, when you use your coffee shop’s wifi, if the connection between your device and the server is insecure, a MitM attacker could lurk there to exploit this. 

Attackers could exploit the Maven issue, by inserting themselves into the users’ network, to interrupt and fail the connection to the Maven Central Repository, causing a downgrade to HTTP source. They could then insert a malicious package to execute their code on the user  machine during development and even in the application environment.

Reducing Enterprise Application Security Risks:

More Work Needs to Be Done

Good News: Maven Released a Fix

Happily, once the issue was reported to Maven, the team released an updated version with a fix. Maven fixed the root cause in their latest version (3.8.1) by adding to the default mirror configuration to block any external URL using HTTP. Doing this means that any user/machine that now builds with the new Maven version won’t connect via HTTP. 

Any attempt to connect via HTTP receives a build error message or even results in a build failure. Even with this fix made by the Maven team, any open source project using HTTP should still change to HTTPS. This is the correct security practice in general and prevents any other potential issues related to using HTTP URIs. 

Bad News: Many Popular Libraries Remain Affected

While this security issue has been resolved, it’s up to Maven users and open source project maintainers to make sure that they are updating to a secure version of Maven. Maintainers also need to update their dependencies to mitigate this risk.  

The WhiteSource Knowledge team analyzed data in the WhiteSource open source database and found that immediately after the new Maven release, many libraries on Maven have yet to be fixed by finding and updating any HTTP calls to HTTPS. 

After scanning all libraries on Maven Central we found that 27% of the libraries remain affected by this vulnerability. 

all maven repositories vs top maven repositories affected by Vulnerability CVE-2021-26291

While it’s tempting to see 27% as negligible and imagine the libraries that you are using in your build have been fixed, scanning the top 50 libraries on Maven Central showed that of the 84% originally affected by this issue, 40% still require remediation.

Jonathan compiled a list of all of the impacted maven GAV coordinates which can be viewed in this GitHub Gist.

Important Notes on Updating to a Secure Maven Version

Considering the data, there is a good chance that if you are a Maven user you need to make sure that you are using version 3.8.1 or higher to ensure connections are secure. Maintainers of popular Maven libraries should also make sure that you are using an updated Maven version in addition to making sure that only HTTPS protocol is in use.

Maven’s update to the settings file includes a new default mirror configuration that ensures any requests sent via HTTP is blocked: 

Any requests sent via HTTP are blocked with this configuration. 

It’s important to note that the fix that blocks HTTP connections is located in the settings file in versions 3.8.1 and higher. Users who have updated to a secure version need to verify that they are using the fix included in the updated settings file. 

It’s Up to Users to Make Sure They Are Using a Secure Maven Version

We tend to take the open source projects that we use in our everyday work for granted. Updates are often messy business, and it’s much easier to believe that open source projects remain secure because of the communities maintaining them. 

The discovery of the security issue in Maven’s POMs default settings and the overwhelming amount of vulnerable libraries and dependencies are a timely reminder that updates can’t be ignored by the community or by users.

Meet The Author

Jonathan Leitschuh

Daniel Elkabes is the vulnerability research team leader and security thought leader at WhiteSource. Daniel has experience as a Security Researcher with a demonstrated history of working in the security industry. Skilled in Reverse Engineering, Vulnerability Research, Malware Research, Computer Forensics and Information Security Research.

Subscribe to Our Blog