SECURITY.md

Report security bugs in Node.js viaHackerOne.

Normally, your report will be acknowledged within 5 days, and you'll receivea more detailed response to your report within 10 days indicating thenext steps in handling your submission. These timelines may extend whenour triage volunteers are away on holiday, particularly at the end of theyear.

After the initial reply to your report, the security team will endeavor to keepyou informed of the progress being made towards a fix and full announcement,and may ask for additional information or guidance surrounding the reportedissue.

The Node.js project engages in an official bug bounty program for securityresearchers and responsible public disclosures. The program is managed throughthe HackerOne platform. Seehttps://hackerone.com/nodejs for further details.

Security bugs in third-party modules should be reported to their respectivemaintainers.

Here is the security disclosure policy for Node.js

• The security report is received and is assigned a primary handler. Thisperson will coordinate the fix and release process. The problem is validatedagainst all supported Node.js versions. Once confirmed, a list of all affectedversions is determined. Code is audited to find any potential similarproblems. Fixes are prepared for all supported releases.These fixes are not committed to the public repository but rather held locallypending the announcement.

• A suggested embargo date for this vulnerability is chosen and a CVE (CommonVulnerabilities and Exposures (CVE®)) is requested for the vulnerability.

• On the embargo date, a copy of the announcement is sent to the Node.jssecurity mailing list. The changes are pushed to the public repository and newbuilds are deployed to nodejs.org. Within 6 hours of the mailing list beingnotified, 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 isissued. However, this may vary depending on the severity of the bug ordifficulty in applying a fix.

• This process can take some time, especially when we need to coordinate withmaintainers of other projects. We will try to handle the bug as quickly aspossible; however, we must follow the release process above to ensure that wehandle disclosure consistently.

When reporting security vulnerabilities, reporters must adhere to the following guidelines:

1. Code of Conduct Compliance: All security reports must comply with ourCode of Conduct. Reports that violate our code of conductwill not be considered and may result in being banned from future participation.

2. No Harmful Actions: Security research and vulnerability reporting must not:

   • Cause damage to running systems or production environments.
   • Disrupt Node.js development or infrastructure.
   • Affect other users' applications or systems.
   • Include actual exploits that could harm users.
   • Involve social engineering or phishing attempts.

3. Responsible Testing: When testing potential vulnerabilities:

   • Use isolated, controlled environments.
   • Do not test on production systems.
   • Do not attempt to access or modify other users' data.
   • Immediately stop testing if unauthorized access is gained accidentally.

4. Report Quality

   • Provide clear, detailed steps to reproduce the vulnerability.
   • Include only the minimum proof of concept required to demonstrate the issue.
   • Remove any malicious payloads or components that could cause harm.

Failure to follow these guidelines may result in:

• Rejection of the vulnerability report.
• Forfeiture of any potential bug bounty.
• Temporary or permanent ban from the bug bounty program.
• Legal action in cases of malicious intent.

In the Node.js threat model, there are trusted elements such as theunderlying operating system. Vulnerabilities that require the compromiseof these trusted elements are outside the scope of the Node.js threatmodel.

For a vulnerability to be eligible for a bug bounty, it must be avulnerability in the context of the Node.js threat model. In otherwords, it cannot assume that a trusted element (such as the operatingsystem) has been compromised.

Being able to cause the following through control of the elements that Node.jsdoes not trust is considered a vulnerability:

• Disclosure or loss of integrity or confidentiality of data protected throughthe correct use of Node.js APIs.
• The unavailability of the runtime, including the unbounded degradation of itsperformance.

If Node.js loads configuration files or runs code by default (without aspecific request from the user), and this is not documented, it is considered avulnerability.Vulnerabilities related to this case may be fixed by a documentation update.

Node.js does NOT trust:

• Data received from the remote end of inbound network connectionsthat are accepted through the use of Node.js APIs andwhich is transformed/validated by Node.js before being passedto the application. This includes:
  • HTTP APIs (all flavors) server APIs.
• The data received from the remote end of outbound network connectionsthat are created through the use of Node.js APIs andwhich is transformed/validated by Node.js before being passedto the application EXCEPT with respect to payload length. Node.js truststhat applications make connections/requests which will avoid payloadsizes that will result in a Denial of Service.
  • HTTP APIs (all flavors) client 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 theuse of Node.js APIs (ex: stdin, stdout, stderr).

In other words, if the data passing through Node.js to/from the applicationcan trigger actions other than those documented for the APIs, there is likelya security vulnerability. Examples of unwanted actions are polluting globals,causing an unrecoverable crash, or any other unexpected side effects that canlead to a loss of confidentiality, integrity, or availability.

For example, if trusted input (like secure application code) is correct,then untrusted input must not lead to arbitrary JavaScript code execution.

Node.js trusts everything else. Examples include:

• 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, WASM and native code, evenif said code is dynamically loaded, e.g., all dependencies installed from thenpm registry.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 theresponsibility of the application to perform the required input validations,e.g. the input toJSON.parse().
• Any connection used for inspector (debugger protocol) regardless of beingopened by command line options or Node.js APIs, and regardless of the remoteend being on the local machine or remote.
• The file system when requiring a module.Seehttps://nodejs.org/api/modules.html#all-together.
• Thenode:wasi module does not currently provide the comprehensive filesystem security properties provided by some WASI runtimes.

Any unexpected behavior from the data manipulation from Node.js Internalfunctions may be considered a vulnerability if they are exploitable viauntrusted resources.

In addition to addressing vulnerabilities based on the above, the project worksto avoid APIs and internal implementations that make it "easy" for applicationcode to use the APIs incorrectly in a way that results in vulnerabilities withinthe application code itself. While we don’t consider those vulnerabilities inNode.js itself and will not necessarily issue a CVE, we do want them to bereported privately to Node.js first.We often choose to work to improve our APIs based on those reports and issuefixes either in regular or security releases depending on how much of a risk tothe community they pose.

• Node.js provides APIs to validate handling of Subject Alternative Names (SANs)in certificates used to connect to a TLS/SSL endpoint. If certificates can becrafted which result in incorrect validation by the Node.js APIs that isconsidered a vulnerability.

• Node.js provides APIs to accept http connections. Those APIs parse theheaders received for a connection and pass them on to the application.Bugs in parsing those headers which can result in request smuggling areconsidered vulnerabilities.

• Node.js provides APIs to encrypt data. Bugs that would allow an attackerto get the original data without requiring the decryption key areconsidered vulnerabilities.

• If Node.js automatically loads a configuration file which is not documentedand modification of that configuration can affect the confidentiality ofdata protected using the Node.js APIs this is considered a vulnerability.

• Code is trusted by Node.js. Therefore any scenario that requires a maliciousthird-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 scenariothat 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 paththat is accessible to it.

• If Node.js automatically loads a configuration file which is documentedno scenario that requires modification of that configuration file isconsidered a vulnerability.

• If Node.js is asked to connect to a remote site and return anartifact, it is not considered a vulnerability if the size ofthat artifact is large enough to impact performance orcause the runtime to run out of resources.

• Corepack defaults to downloading the latest version of the software requestedby the user, or a specific version requested by the user. For this reason,Node.js releases won't be affected by such vulnerabilities. Users areresponsible for keeping the software they use through Corepack up-to-date.

Experimental features are eligible to reports as any other stable feature ofNode.js. They will also be susceptible to receiving the same severity scoreas any other stable feature.

Security notifications will be distributed via the following methods.

• https://groups.google.com/group/nodejs-sec
• https://nodejs.org/en/blog/vulnerability

If you have suggestions on how this process could be improved, please visitthenodejs/security-wgrepository.

There aren’t any published security advisories