May Open Source Security Vulnerabilities Snapshot
Table of Contents
May is here, and with it our May’s open source security snapshot, our monthly overview of the new open source security vulnerabilities published in April, to see what’s new in the ever-evolving open source security ecosystem.
In order to give you all the low-down on emerging or ongoing trends, our hardworking research team analyzed all of the new open source security vulnerabilities added to the Mend.io database. Our extensive open source vulnerabilities database continuously aggregates information from several resources like the well-known National Vulnerability Database (NVD), in addition to other publicly available security advisories and issue trackers in the open source and security communities.
Open source vulnerabilities in April: What’s new?
Nearly 600 new open source vulnerabilities were published in April, a slight decline compared to March. Pandemic or not, the open source community continues to work hard to discover and publish open source security vulnerabilities and their fixes in the projects we all know and love. The result is that almost 70% of these vulnerabilities were published with a fix already available.
It’s also important to note that over 10% of the open source vulnerabilities were published on platforms other than the NVD. While many in the security and development communities are familiar with the comprehensive NVD, due to the decentralized nature of the open source community, many issues are still published outside of it in community issue trackers and security advisories. That’s why managing open source security successfully requires tracking more than just the NVD data.
Open source vulnerabilities severity breakdown in April
Since many development and security teams look to security vulnerabilities’ severity when trying to decide which issues to address first, we also checked the distribution of the severity scores in the open source security vulnerabilities published in April.
Looking at the severity distribution and the fact that almost 60% of April’s open source security vulnerabilities are either high or critical severity, it’s clear that relying on severity scores will only get security and development teams so far in their attempts to determine which issues to focus on first.
The main takeaway here is that the security research community is focused on discovering and disclosing high-severity issues, the CVSS score is meant to measure severity, rather than risk. Development teams, on the other hand, are bombarded by security alerts and need to look at all the parameters that will help them efficiently prioritize what to fix first. Depending only on severity can only take developers so far when they want to remediate the most urgent issues, fast.
Most common open source CWEs in April
We also looked at which types of CWEs were most prominent and found that the top three most common CWEs in April are consistent with data from previous months and years.
CWE-79 (XSS) is once again the most common vulnerability type, achieving this dubious win with quite a substantial lead. There are a number of factors that explain this continuous trend. One is that CWE-79 is easy to detect with the help of automated security research tools. Another is that this is a common vulnerability in web applications, which have been getting increased attention from the security community.
It’s also worth noting that CWE-79 is often a result of basic coding mistakes that could easily be avoided when we comply with coding standards and best practices.
April open source vulnerabilities per programming language
Since developers can become quite passionate when discussing the pros and cons of their favorite programming language, we also checked the distribution of April’s new open source security vulnerabilities per language.
It should come as no surprise that C had the highest number of new vulnerabilities in April since it has been in use for far longer than the rest of the popular programming languages. C is the language used in most of the products and platforms we use, including the Linux kernel, where quite a number of new vulnerabilities were published this month.
JavaScript also saw a lot of vulnerabilities this month, which makes sense since XSS issues are very common to JavaScript. In the next section, we’ll turn the spotlight on two XSS vulnerabilities found in jQuery this April.
Spotlight on CWE-79 in jQuery
We focused our spotlight on jQuery, the extremely popular open source JavaScript library, where two new XSS issues were published this month.
CVE-2020-11022, rated with a medium 6.9 CVSS v3.x score, was found in jQuery versions greater than or equal to 1.2 and before 3.5.0. According to GitHub’s Security Advisory, passing HTML from untrusted sources to one of jQuery’s DOM manipulation methods (like html(), .append(), and others) may execute untrusted code, even after sanitizing it. This issue was fixed in jQuery version 3.5.0, and you can take a closer look at the fix on GitHub.
The second XSS issue discovered in jQuery in April is CVE-2020-11023, which got the same 6.9 CVSS score, and applies to versions greater than or equal to 1.0.3 and before 3.5.0. Here, passing HTML containingelements from untrusted sources to one of jQuery’s DOM manipulation methods (i.e., .html(), .append(), and others) may execute untrusted code. This was also fixed in jQuery version 3.5.0.
In both cases, jQuery.htmlPrefilter function was responsible for validating the XHTML tags with a regex query, but the jQuery team recently found that there were some edge cases where regex parsing could result in an XSS vulnerability.
The jQuery team decided to remove the regex in its new version (3.5.0). Now, the strings are passing through without the problematic function. For developers, this doesn’t mean the vulnerability is completely solved. On the contrary, now you need to implement an XHTML validator in your own code to ensure each scenario is handled appropriately, including the aforementioned edge cases. This solution actually puts more responsibility on developers to ensure secure validation.
jQuery added that while it’s not recommended, “If you absolutely need the old behavior, using the latest version of the jQuery migrate plugin provides a function to restore the old jQuery.htmlPrefilter. After including the plugin you can call jQuery.UNSAFE_restoreLegacyHtmlPrefilter() and jQuery will again ensure XHTML-compliant closing tags.
jQuery also added a workaround: “To sanitize user input properly, we also recommend using dompurify with the SAFE_FOR_JQUERY option to sanitize HTML from a user. If you don’t need the old behavior, but would still like to sanitize HTML from a user, dompurify should be used without the SAFE_FOR_JQUERY option, starting in jQuery 3.5.0. For more details, please see the 3.5 Upgrade Guide.”
This is another reminder that it’s up to us to maintain secure coding practices and make sure that we follow the community’s advisories.
Mind your code: Staying on top of open source security vulnerabilities
May’s open source vulnerabilities snapshot shows us that staying on top of our open source security is as important as ever.
The DevSecOps approach has taught us that it takes a village, and a few automated tools, to ensure our processes are agile and our products are secure. The data we found this month provides us with more evidence that shifting left is critical to this process, and it all starts with secure coding. Making sure that the open source components are secure and updated from the very start, and following secure coding standards will take development and security teams a long way when it comes to managing their open source security.
Want to learn more about April’s top open source security vulnerabilities? Check out Mend’s Vulnerability Database.
