Fetching contributors…
Cannot retrieve contributors at this time
133 lines (85 sloc) 4.96 KB

This document describes the management of vulnerabilities within the Node.js ecosystem. Vulnerabilities in Node.js core are out of this scope.


  • package: in this document, a package is a module available for use with Node.js and hosted on the repository.


Individuals who find potential vulnerabilities in a package are invited to complete a vulnerability report on the dedicated HackerOne organization:

Vulnerabilities can also be reported by emailing

When a potential vulnerability is reported, the following actions are taken:


Who: The triage team

Delay: 2 business days

Within 2 business days, a member of the triage team provides a first answer to the individual who submitted the potential vulnerability. The possible responses can be:

  • Acceptance: what was reported is considered as a new vulnerability
  • Rejection: what was reported is not considered as a new vulnerability
  • Need more information: the triage team needs more information in order to evaluate what was reported.

Triaging should include updating issue fields:

  • Asset - set/create the module affected by the report
  • Severity - TBD, currently left empty

Reference: HackerOne: How do I triage a report?

Correction follow-up

Who: A member of the triage team

Delay: 45 days

When a vulnerability is confirmed, a member of the triage team is designated to follow up on this report.

With the help of the individual who reported the vulnerability, they contact the maintainers of the vulnerable package to make them aware of the vulnerability. The maintainers can be invited as participants to the reported issue.

With the package maintainer, they define a release date for the publication of the vulnerability. Ideally, this release date should not happen before the package has been patched.

If the maintainers are unreachable, the vulnerability is to be made public 45 days after the triage date.


Who: A member of the triage team

Delay: 45 days

Within 45 days after the triage date, the vulnerability must be made public.

Severity: Vulnerability severity is assessed using CVSS v.3. More information can be found on HackerOne documentation

If a patch is being actively developed by the package maintainer, an additional delay can be added with the approval of the triage team and the individual who reported the vulnerability (this is a simple vote where each member of the triage team and the vulnerability reporter have 1 vote each).

At this point, a CVE should be requested through the HackerOne platform through email that should include the Report ID and a summary.

The vulnerability is considered as published when a Pull Request adding it to this repository is opened.

Within HackerOne, this is handled through a "public disclosure request".

Reference: HackerOne: How does public disclosure work?

Vulnerabilities found outside this process

Vulnerabilities found and fixed outside this process should be added into the vulnerability database. This can be done by anyone through a Pull Request on this repository.

The vulnerability should include any kind of supporting material such as references, maintainer review or otherwise to confirm the vulnerability report is valid.

The triage team

The triage team is composed of 5 or more members of the security working group. This team is approved and modified by a vote from the working group.

They are responsible for the management of this process.

Each member of the triage team is expected to handle vulnerabilities on a regular basis.

Members of this team are required to follow the same NDA and privacy measures as the Node.js Security Team.

Use of CVEs and reference

Every vulnerability disclosed by the triage team through HackerOne must be assigned a CVE number.

Vulnerabilities disclosed to this repository without using HackerOne currently cannot be assigned a CVE by the triage team (we are working to resolve this) but may have a CVE number if was assigned by another entity.


Members of the security teams should indicate that they accept the privacy policies by PRing their acceptance to this file:

  • @brycebaril - Bryce Baril
  • @cjihrig - Colin Ihrig
  • @dgonzalez - David Gonzalez
  • @elexy - Alex Knol
  • @grnd - Danny Grander
  • @lirantal - Liran Tal
  • @MarcinHoppe - Marcin Hoppe
  • @pxlpnk - Andreas Tiefenthaler
  • @vdeturckheim - Vladimir de Turckheim

Emeritus Members

  • @bengl - Bryan English
  • @gergelyke - Gergely Nemeth