Report security bugs in Node.js via HackerOne.
Your report will be acknowledged within 5 days, and you'll receive a more detailed response to your report within 10 days indicating the next steps in handling your submission.
After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue.
The Node.js project engages in an official bug bounty program for security researchers and responsible public disclosures. The program is managed through the HackerOne platform. See https://hackerone.com/nodejs for further details.
Security bugs in third party modules should be reported to their respective maintainers.
Here is the security disclosure policy for Node.js
-
The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.
-
A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.
-
On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.
-
Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.
-
This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible; however, it's important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.
Being able to cause a negative outcome in a way that requires control of the elements that are trusted by Node.js is not considered a vulnerability in Node.js.
Being able to cause the following through control of the elements that Node.js does not trust is considered a vulnerability:
- Disclosure or loss of integrity or confidentiality of data protected through the correct use of Node.js APIs.
- The unavailability of the runtime, including the unbounded degradation of its performance.
If Node.js loads configuration files or runs code by default (without a specific request from the user), and this is not documented, it is considered a vulnerability. Vulnerabilities related to this case may be fixed by a documentation update.
Node.js does NOT trust
- The data from network connections that are created through the use of Node.js
APIs and which is transformed/validated by Node.js before being passed to the
application. This includes:
- HTTP APIs (all flavors) client and server APIs.
- DNS APIs.
- Consumers of data protected through the use of Node.js APIs (for example people who have access to data encrypted through the Node.js crypto APIs).
- The file content or other I/O that is opened for reading or writing by the use of Node.js APIs (ex: stdin, stdout, stderr). In other words, if the content passing through Node.js to/from the application can trigger actions other than those documented for the APIs, the content is not trusted avoid causing those actions.
Node.js trusts everything else. As some examples this includes:
- The developers and infrastructure that runs it.
- The operating system that Node.js is running under and its configuration, along with anything under control of the operating system.
- The code it is asked to run including JavaScript and native code, even if said code is dynamically loaded. The code run inherits all the privileges of the execution user.
- Inputs provided to it by the code it is asked to run, as it is the responsibility of the application to perform the required input validations.
- Any connection used for inspector (debugger protocol) regardless of being opened by command line options or Node.js APIs, and regardless of the remote end being on the local machine or remote.
- The file system when requiring a module. See https://nodejs.org/api/modules.html#all-together.
Any unexpected behavior from the data manipulation from Node.js Internal functions are considered a vulnerability.
In addition to addressing vulnerabilities based on the above, the project works to avoid APIs and internal implementations that make it “easy” for application code to use the APIs incorrectly in a way that results in vulnerabilities within the application code itself. While we don’t consider those vulnerabilities in Node.js itself and will not necessarily issue a CVE we do want them to be reported privately to Node.js first. We often choose to work to improve our APIs based on those reports and issue fixes either in regular or security releases depending on how much of a risk to the community they pose.
- Code is trusted by Node.js, therefore any scenario that requires a malicious third-party module cannot result in a vulnerability in Node.js.
- Node.js trusts the inputs provided to it by application code. It is up to the application to sanitize appropriately, therefore any scenario that requires control over user input is not considered a vulnerability.
- Node.js trusts the file system in the environment accessible to it. Therefore, it is not a vulnerability if it accesses/loads files from any path that is accessible to it.
Security notifications will be distributed via the following methods.
If you have suggestions on how this process could be improved please submit a pull request or file an issue to discuss.