• Home
  • Blog
  • June 2020 Open Source Security Vulnerabilities Snapshot

June 2020 Open Source Security Vulnerabilities Snapshot

It’s time for June’s open source vulnerabilities snapshot, your monthly overview of everything new in the fast-paced world of open source security vulnerabilities. 

In hopes of giving you this month-at-a-glance summary of current trends in the open source ecosystem, our trusted research team reviewed the new open source security vulnerabilities published in May and collected by the Mend database. Mend’s comprehensive open source vulnerabilities database continuously aggregates information from a variety of sources, ranging from the National Vulnerability Database (NVD) to peer-reviewed security advisories and issue trackers in the open-source and security communities. 

Open Source Vulnerabilities in June: What’s New?

Five hundred new open source vulnerabilities were published in May. Come rain or shine or pandemic, the open source community continues to invest significant efforts in finding and fixing issues in open source projects. Happily, almost 50% of the open source security vulnerabilities published in May already have a fix already available, and these numbers are sure to rise in the upcoming weeks, making it that much easier for all of us to manage the security of the open source components that we’re using. 

May Open source Vulnerabilities Published with a Fix

Open Source Vulnerabilities Severity Breakdown in May

We looked at how May’s vulnerabilities’ severity scores were distributed since this is usually a deciding factor for development and security teams when determining which new alerts to address first. 

May Open Source Vulnerabilities Severity Breakdown

Looking at the data, it’s clear that severity scores aren’t enough when attempting to prioritize vulnerabilities when over 50% of them are rated high or critical.  

There are several reasons why the distribution of scores is so uneven. Understandably, the security research community invests resources in discovering and disclosing high-severity issues, resulting in fewer low and medium vulnerabilities published. While severity score should be one consideration when prioritizing security alerts for new vulnerabilities, it’s important to remember that it can’t be the only consideration. The CVSS score is meant to measure severity, not risk. The risk and the impact of a vulnerability on a software product depend on a number of additional aspects that should be considered. 

Most Common Open Source CWEs in May

The three most common CWEs in May remain CWE-79 (XSS), CWE-20 (Improper Input Validation), CWE-200 (Information Exposure), and XSS vulnerabilities have quite the lead. 

May Open Source Vulnerabilities: Top Five CWEs

CWE-79 (XSS) has been the most common vulnerability type over the past two years and has been one of the three most common CWEs for several years prior. The increasing use of automated tools for the detection of XSS issues is one reason behind the high number of new XSS issues discovered in open source components month after month. Another explanation is the attention the security community has been directing towards web application security, where CWE-79 can be found.  

As XSS vulnerabilities continuously increase, it’s important to remember that this issue can be avoided at the coding stage, by simply following basic coding standards and best practices. While early detection of issues is extremely important, secure coding is also a critical step in shifting security left.

May Open Source Vulnerabilities per Programming Language

We also found that the distribution of new open source vulnerabilities per programming language in May is fairly consistent with April’s results. 

May Open Source Vulnerabilities per Programming Language

In May, 25% of the open source vulnerabilities published were in libraries written in C. Considering the amount of code written in C and the size of the communities behind applications like the Linux kernel, this should come as no surprise. Linus’s Law states that “given enough eyeballs, all bugs are shallow.” When we look at a language as prominent and popular as C, a high number of published vulnerabilities is to be expected. 

Not far behind C with a high number of vulnerabilities published in May is JavaScript, a language with extremely popular projects supported by an active open source community.  

Spotlight on WS-2020-0091 in http-proxy

Severity: High, 7.5

Vulnerable versions: http-proxy prior to 1.18.1

Speaking of a rise in JavaScript vulnerabilities, we focused our spotlight on WS-2020-0091, a vulnerability in node-http-proxy, an HTTP programmable proxying library that supports websockets and helps to implement components like reverse proxies and load balancers. 

According to the NPM security advisory, vulnerable versions of http-proxy are open to a Denial of Service attack. The advisory warns that in cases where the proxy server sets headers in the proxy request using a specific function, an HTTP request with a long body triggers an unhandled exception that crashes the proxy server. 

One example that the advisory provides is “for a proxy server running on http://localhost:3000, the following curl request triggers the unhandled exception:

curl -XPOST http://localhost:3000 -d “$(python -c ‘print(“x”*1025)’)”

Considering the library has over 8.5 million weekly downloads from npm and over 1,900 dependents, including some extremely popular projects, it’s extremely important to make sure that you are using an updated version. 

The good folks at http-proxy have fixed the issue, and remediation requires upgrading to version 1.18.1. You can learn more about the fix in the pull request on GitHub

You might be wondering why this vulnerability’s ID begins with a WS rather than the more common CVE prefix. This is because the issue hasn’t been listed in the CVE yet. While many rely on the CVE and NVD as the primary resources for information about security vulnerabilities, sometimes it takes a while for open source issues to be added there. Due to the decentralized nature of the open source community, open source vulnerabilities are often published in an advisory, forum, or issue tracker before being indexed in the CVE. These issues are added to the Mend database with a WS prefix. 

This is another reminder that relying exclusively on the CVE or NVD is not enough to fully cover all of the open source vulnerabilities in your code. 

Don’t Let the Open Source Security Vulnerabilities Keep You Down

The open source and security research communities continue to work hard to uncover and publish open source security vulnerabilities in the software projects that we are all using. The next step is up to us, the users of open source components. 

Managing open source security is not for the faint of heart, but it’s a challenge we can’t ignore. We need to address the open source vulnerabilities in our code as soon as possible, without slowing down development or delaying release.

If we want to check all of our open source security boxes, DevOps, development, and security teams must work together, implementing the right processes and tools as early as possible in the development lifecycle. Making the right decisions from the earliest stages of coding and continuously tracking our open source components and vulnerabilities throughout the DevOps pipeline will help us get to our release dates quickly and securely. 

Want to learn more about May’s top open source security vulnerabilities? Check out Mend’s Vulnerability Database.

Meet The Author

Adam Murray

Adam Murray is a content writer at Mend. He began his career in corporate communications and PR, in London and New York, before moving to Tel Aviv. He’s spent the last ten years working with tech companies like Amdocs, Gilat Satellite Systems, Allot Communications, and Sisense. He holds a Ph.D. in English Literature. When he’s not spending time with his wife and son, he’s preoccupied with his beloved football team, Tottenham Hotspur.

Subscribe to Our Blog