Security Research

[CVE-2020-15779] Path Traversal in NPM module

Title: Path Traversal in NPM module
Date: 18/05/2020
CVE-ID: 2020-15779
Author: Thomas Sermpinis
Versions: <= 2.0.31
Package URL:
Tested on: node v10.19.0, v2.0.31, v2.3.0
Proof of Concept:

During one of my penetration tests for a local military equipment supplier, I faced a web application running on an embedded device that used web sockets in order to initiate the connection between the server and the client. There are several different technologies that can be used in the back-end system in order to make use of web sockets, but the client made use of

The web application was relatively small, with only a few entry points that did not seem to be vulnerable. All the modules were up to date and my enumeration started to go into a dead end. As there were more days for my pentest, I decided to dig deeper and I started analyzing more the request and researching about the npm modules that were included and were in use in the web application.

One of the functionalities was a configuration file upload, that was stored in a folder in the filesystem, by using the npm module. (2.0.31) is a node module for uploading files via the module. Playing around with the requests I managed to bypass the restrictions and upload a file in a different folder from the expected one (I knew that as I had access to the backend of the system).

Client and project aside, the upload functionality of is vulnerable to improper input validation, allowing attackers to bypass upload directory restrictions and it allows them to upload files to paths of their choice in the underlying system.

Description of Vulnerability

The default configuration of comes with an upload functionality handled by websockets. When a user tries to upload a file with the web application, the following client side request is created in order for the file to be created:

Figure 1: Normal websocket request for file upload with


In order for this file to be created to the underlying system, the code from index.js of is executed and the following part of the code, manages to merge the file path (supplied by the configuration) with the file name that was supplied by the user:

if(typeof options.uploadDir === 'string') {uploadDir = path.join(options.uploadDir, filename);}

As an example, if the user uploads a file with the name “testfile.mp3” and the server is configured to store files in the 
path the resulting path that will create the file, will be 

Because the aforementioned code makes no check on the file name, the upload request can be intercepted and the file name altered in a way that will move in certain paths of the system. The following example exploits this issue:


This request will generate the following path for the file to be stored 
which means that the file will be actually be created in the 
as the ../ characters will move the path one level lower in the filesystem.

Figure 2: File created in the node_modules directory of the filesystem, outside the intended directory.

From this example we can understand that we can write in several sensitive directories like the ~/ home directory (which includes the .ssh folder which allows us to rewrite the ssh configuration), in the root webserver directory (which can help us get a reverse shell under the right circumstances) and the cron directory (where we can inject cron jobs for code execution). Additionally, if the back-end system runs with superuser privileges (which is not so uncommon), the attacker can use this vulnerability to create files in even more sensitive paths (e.g. /root and /etc). As an example, we can write the /etc/passd file of our implementation like the following:


Issue Replication

In order to replicate the issue, the following steps have to be executed:

  • Setup a proxy to intercept HTTP and WebSocket requests (e.g. Burp Suite or OWASP Zap)
  • Upload a file using the web application and intercept the websocket request
  • Change the “name” parameter by adding ../ and specifying the needed path:
    • 42["",{"id":"u_0","name":"../../../Downloads/testfile.mp3","size":1,"chunkSize":10240,"sent":0,"data":{}}]
    • This example will create the testfile.mp3 file in the Downloads directory of the current user (our test server stores files in /home/ubuntutest/Documents/socket-app/data)


No fix is currently available. Consider using an alternative package until a fix is made available.

Vulnerability Disclosure Timeline

Following the npm guidelines for vulnerability disclosure (“If maintainers are unresponsive after 45 days, npm Security makes the advisory public”), we responsibly disclosed this vulnerability on 18th of May 2020.

  • Initial Disclosure: 18th May 2020
  • Security Team Validation: 18th May 2020
  • Advisory Release: 7th July 2020
  • CVE-ID Assignment: 15th July 2020
  • PoC Release at 27th July 2020