The NodeJS component express-fileupload - touting 7 million downloads from the npm registry - now has a critical Prototype Pollution vulnerability.
At a minimum, this vulnerability lets attackers toy with your NodeJS applications and cause a series of HTTP 500 errors (i.e., Denial of Service (DoS)). More advanced exploits target the template-altering capabilities of the flaw, enabling hackers to execute remote code on a vulnerable machine.
The NodeJS component “express-fileupload” is a rather popular choice among developers because it provides a variety of file upload options, and can be easily integrated into your application. If you are relying on a vulnerable “express-fileupload” version for file upload functionality, you should be aware of the security risks it can cause.
The vulnerability (CVE-2020-7699) was discovered by security researcher Posix at the end of July, where he provided more details in this blog post.
Why Prototype Pollution vulnerabilities matter?
But ever since the advent of “serverless” architecture and NodeJS-powered apps, the same language (JS), now powers thousands of backend apps. This presents a far higher security risk to everyone, if organizations do not stay up to date with the latest NodeJS vulnerabilities and patch as required.
With Prototype Pollution vulnerabilities like these, all it takes is a single HTTP request for an attacker to get shell access and remotely execute commands on a server running “express-fileupload” along with other open-source libraries (e.g., EJS).
A reverse shell PoC exploiting CVE-2020-7699
Source: Posix blog
How does Sonatype get this right?
As soon as the Sonatype Security Research team was made aware of the vulnerability impacting this heavily-downloaded component, we expedited our deep dive research. During the research, we realized that the official NVD advisory was incorrect because even though public discourse on forums stated that version 1.1.8 is fixed, it was only partially fixed.
In the fix made to 1.1.8, while the uploaded JSON values containing ‘__proto__’ are deemed invalid and filtered, the logic doesn’t yet take into account another variation of the exploit.
Partial fix applied by “express-fileupload” for the vulnerability in 1.1.8
As pointed out by a user securityMB, an attacker can simply use “constructor.prototype” as opposed to the “__proto__” mutator to bypass this check, and still pollute the prototype of objects.
Noticing this, the highly responsive project developers were quick to deprecate version 1.1.8 from npm downloads and issue an improved fix, which went into version 1.1.9:
Improved fix that went into version 1.1.9 of “express-fileupload” (via GitHub)
Furthermore, to extend the protections offered by this fix to arrays, and preventing modification of object methods and properties other than “__proto__” and “constructor,” the project has yet again made some enhancements in versions 1.1.10 and above. This is all accounted for in Sonatype’s data.
Further enhancement which extends protections to arrays and other object methods
The responsiveness demonstrated by the “express-fileupload” team in patching the flaw is commendable, as is the responsible disclosure on the researcher’s (Posix) part.
But, this vulnerable component that has more than 7 million downloads could easily be lurking in your software supply chain.
Without complete insights, as provided by Sonatype, some developers may continue to use version 1.1.8 under the false impression it is patched, which, as we saw, isn’t the case. Sonatype recommends upgrading to express-fileupload version 1.1.10 or above, as present in npm downloads, which contains the fix for this vulnerability.
With thousands of vulnerabilities reported every year in open source components, it is virtually impossible to manually keep track of each exploit and how it specifically applies to your app dev environment. DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of malicious intent. Sonatype Nexus customers were notified of CVE-2020-7699 within hours of the discovery, and their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to find out quickly.
Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.