Writing Quality Vulnerability Reports

npm offers a way for security researchers, package users, package maintainers, and community members to report security vulnerabilities via the “Report a Vulnerability” button on npm Package pages. This provides the community a way to participate in coordinated disclosure with the package maintainer instead of opening a public issue, which could put users at risk.

These reports go directly to the npm Security team for triage instead of to the package maintainers. This is our way of helping the community spend less time on low-quality security reports.

In order for us to make sure reported vulnerabilities are handled rapidly and effectively, we need you, our community, to provide us with actionable, detailed information. Here’s some basic do’s and don’ts for your security report:

What should be included in a quality security report

• The package name and version where you experienced the vulnerability. Example: marked@1.0.0 or marked@*
  
• A short description of the vulnerability and its impact. Example: “If a user is able to control input into the function foo then the user is able to execute commands giving the attacker the same access as the user running the application.”
  
• Details of the environment in which you experienced the vulnerability. Example: “This was found to be exploitable using node.js 6.0.0 on OSX, but was not tested using any other platform or Node.js version.”
  
• A demonstrable proof of concept or steps to reproduce the same result. This helps the npm Security team efficiently triage the issue (see the example below).
  
• Any particular references, code snippets, or documents that might help the npm Security team or the maintainer better understand (see the example below).
  

What should not be reported

• Reports without actionable context are very time-consuming for our team to adequately process. These requests should go to the package maintainer in the form of an issue.
  
• The output of npm audit - As the npm Security team already knows about these flaws, it’s better to reach out to the maintainer directly to update dependency versions.
  
• General feature requests
  
• Stack traces or errors without explanation as to what security impact they have.
  

Also note: Vulnerabilities in the npm Registry, website, or other core services and tooling should be reported to security@npmjs.com.

Example quality report

I would like to report a command injection vulnerability in the “foobarbaz” package, version 1.0.0.

Follow the below steps to reproduce this vulnerability.

Environment:

Node.js v10.9.0 on Linux

1. npm i foobarbaz@1.0.0

2. Create the following proof-of-concept:

The code below illustrates the issue. Executing this code in a directory that contains the file existingfile.zip (a valid zip file that exists on disk, does not necessarily have to be attacker controlled) will also execute the supplied touch xyz command creating a file, but this could be any command the user executing the code has permission to run.

‘‘‘

var foo = require('foobarbaz');

var unzip = foo.unzip;

// Gather user input from some source. In this case we simulate it with a string

var userinput = './existingfile.zip; touch xyz"';

// This line calls the vulnerable method with our user input.

unzip(userinput, './unzipped', function(){});

‘‘‘

Thank you

We’re grateful for our community’s continual efforts to identify and report vulnerabilities and we look forward to your future submissions. We will continue to improve our tools and resources so that npm remains the source of trusted JavaScript.