Security

Reporting a bug in Node.js

Report security bugs in Node.js via HackerOne.

Normally, 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. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.

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.

If you do not receive an acknowledgement of your report within 6 business days, or if you cannot find a private security contact for the project, you may escalate to the OpenJS Foundation CNA at security@lists.openjsf.org.

If the project acknowledges your report but does not provide any further response or engagement within 14 days, escalation is also appropriate.

Node.js bug bounty program

The Node.js project no longer has a bug bounty program.

Reporting a bug in a third-party module

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

Disclosure policy

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 validated against all supported Node.js versions. Once confirmed, a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all supported releases. 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, a copy of the announcement is sent to the Node.js security mailing list. 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 we need to coordinate with maintainers of other projects. We will try to handle the bug as quickly as possible; however, we must follow the release process above to ensure that we handle disclosure consistently.

Code of Conduct and Vulnerability Reporting Guidelines

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

1. Code of Conduct Compliance: All security reports must comply with our Code of Conduct. Reports that violate our code of conduct will 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 without prior authorization. Contact the Node.js Technical Steering Committee (tsc@iojs.org) for permission or open a HackerOne report.
   • 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 reproducible code written in JavaScript.
   • 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.

The Node.js threat model

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

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

Experimental platforms

Node.js maintains a tier-based support system for operating systems and hardware combinations (Tier 1, Tier 2, and Experimental). For platforms classified as “Experimental” in the supported platforms documentation:

• Security vulnerabilities that only affect experimental platforms will not be accepted as valid security issues.
• Any issues on experimental platforms will be treated as normal bugs.
• No CVEs will be issued for issues that only affect experimental platforms
• Bug bounty rewards are not available for experimental platform-specific issues

This policy recognizes that experimental platforms may not compile, may not pass the test suite, and do not have the same level of testing and support infrastructure as Tier 1 and Tier 2 platforms.

Experimental features behind compile-time flags, experimental runtime flags, and V8 flags

Node.js includes certain experimental features that are only available when Node.js is compiled with specific flags or that are only enabled with experimental runtime flags. These features are intended for development, debugging, or testing purposes and are not enabled or supported in official releases.

Node.js may also expose V8 features that are controlled by V8 command-line flags (e.g., --js-staging, --max_old_space_size). These flags enable or modify V8-level JavaScript engine behavior that is not part of the ECMAScript specification that Node.js implements and is not part of the Node.js documented API surface.

Runtime gated experimental features

Experimental features behind runtime flags can fall into one of three categoriesgithub:

• 1.0 - Early development.
• 1.1 - Active development.
• 1.2 - Release candidate.

Security vulnerabilities that only affect experimental features in either the 1.0 or 1.1 stages, and that are gated with an --experimental-* runtime flag requiring explicit opt-in by the user to enable, will not be accepted as valid security issues unless the vulnerability can be exploited in a way that impacts the security of a stable feature when the associated --experimental-* flag is not enabled.

Security vulnerabilities that affect experimental features in the 1.2 stage are acceptable as valid security issues.

Compile-time gated experimental features and V8 flags

• Security vulnerabilities that only affect features behind compile-time flags or V8 flags that are not enabled by default will not be accepted as valid security issues.
• Any issues with these features will be treated as normal bugs.
• No CVEs will be issued for issues that only affect compile-time flag or V8 flag features.
• Bug bounty rewards are not available for compile-time flag or V8 flag feature issues.

This policy recognizes that experimental features behind compile-time flags are not ready for public consumption and may have incomplete implementations, missing security hardening, or other limitations that make them unsuitable for production use. Similarly, V8 flags expose internal V8 engine options that are not part of the Node.js documented API surface, are not enabled by default in production builds, and may have incomplete implementations or missing security hardening.

Security triage dispositions

When triaging a report, the project classifies it into one of the following dispositions:

• Vulnerability: A Node.js defect that is exploitable across a Node.js-owned security boundary and meets the criteria under What constitutes a vulnerability, including any applicable DoS criteria.
• Security-interest bug: A real Node.js defect, or an API behavior likely to cause security bugs in applications, that is not itself a vulnerability under this threat model. These are fixed as regular bugs and do not automatically receive a CVE, but should still be reported privately first when they affect a common security control such as protocol interpretation, permission enforcement, or certificate/TLS decisions.
• Common bug: A correctness, robustness, or crash issue without a Node.js-owned security boundary or a realistic cross-boundary attacker benefit.
• Invalid / out of scope: A bug report that meets one of these criteria:
  • Cannot be reproduced
  • Is not a Node.js defect (e.g., an application bug)
  • Is excluded by policy (e.g., experimental features)

What constitutes a vulnerability

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.

Denial of Service (DoS) vulnerabilities

For a behavior to be considered a DoS vulnerability, the PoC must meet the following criteria:

• The API is being correctly used.
• The API doesn’t have a warning against its usage in a production environment.
• The API is public and documented. If the API comes from JavaScript, the behavior must be well-defined in the ECMAScript specification.
• The API has stable (2.0) status.
• The behavior is significant enough to cause a denial of service quickly or in a context not controlled by the Node.js application developer (for example, HTTP parsing).
• The behavior is directly exploitable by an untrusted source without requiring application mistakes.
• The behavior cannot be reasonably mitigated through standard operational practices (like process recycling).
• The behavior occurs deterministically under normal usage patterns rather than edge cases.
• The behavior occurs at a rate that would cause practical resource exhaustion within a practical timeframe under typical workloads.
• The attack demonstrates asymmetric resource consumption, where the attacker expends significantly fewer resources than what’s required by the server to process the attack. Attacks requiring comparable resources on the attacker’s side (which can be mitigated through common practices like rate limiting) may not qualify.

Node.js does NOT trust:

• Data received from the remote end of inbound network connections that are accepted 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) server APIs.
• The data received from the remote end of outbound 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 except with respect to payload length. Node.js trusts that applications make connections/requests which will avoid payload sizes 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 the use of Node.js APIs (ex: stdin, stdout, stderr).

In other words, if the data passing through Node.js to/from the application can trigger actions other than those documented for the APIs, there is likely a security vulnerability. Examples of unwanted actions are polluting globals, causing an unrecoverable crash, or any other unexpected side effects that can lead 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 run it.
• The operating system that Node.js is running under and its configuration, along with anything under the control of the operating system. An attacker who can already run commands on the host and uses an official, signed Node.js binary to execute malicious JavaScript does not exploit a vulnerability in Node.js. A code signature identifies the publisher of the Node.js binary; it is not a statement about the trustworthiness of the scripts that binary executes.
• The deployment network environment for the privacy of traffic and routing decisions, including internal networks through which Node.js traffic passes and configured HTTP(S) proxy servers. Built-in proxy support is intended to route traffic through proxies authorized for the deployment, often because a firewall requires one to access external networks. It is not intended to hide traffic from network operators or authorities governing the deployment. Untrusted or unauthorized proxies, as well as deployment policy or legal compliance controls around proxy use, are the responsibility of the deployment operator and are outside this threat model. This does not change that data parsed from network protocol peers is untrusted as described above.
• The code it is asked to run, including JavaScript, WASM and native code, even if said code is dynamically loaded, e.g., all dependencies installed from the npm registry or libraries loaded via node:ffi. 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, e.g. the input to JSON.parse().
• 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.
• The node:wasi module does not currently provide the comprehensive file system security properties provided by some WASI runtimes.
• The execution path is trusted. Additionally, Node.js path manipulation functions such as path.join() and path.normalize() trust their input. Reports about issues related to these functions that rely on unsanitized input are not considered vulnerabilities requiring CVEs, as it’s the user’s responsibility to sanitize path inputs according to their security requirements.

Any unexpected behavior from the data manipulation from Node.js Internal functions may be considered a vulnerability if they are exploitable via untrusted resources.

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.

Examples of vulnerabilities

Improper Certificate Validation (CWE-295)

• 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 be crafted that result in incorrect validation by the Node.js APIs that is considered a vulnerability.

Inconsistent Interpretation of HTTP Requests (CWE-444)

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

Missing Cryptographic Step (CWE-325)

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

External Control of System or Configuration Setting (CWE-15)

• If Node.js automatically loads a configuration file that is not documented and modification of that configuration can affect the confidentiality of data protected using the Node.js APIs, then this is considered a vulnerability.

Examples of non-vulnerabilities

Defense-in-depth issues

• Bugs whose fixes would only improve resilience after another security boundary has already failed, or reduce the impact of an issue outside the Node.js threat model, are considered defense-in-depth issues.
• Defense-in-depth issues are never treated as Node.js security vulnerabilities, do not receive CVEs, and are handled as regular bugs or hardening improvements.

Malicious protocol peers

• Node.js treats data from remote network peers as untrusted, and bugs in parsers or protocol implementations may be security vulnerabilities.
• Node.js treats data from HTTP/1.1 keep-alive connections as trusted, meaning that a Node.js client consuming unsolicited or misordered responses within the same HTTP/1.1 connection reuse lifecycle are generally not considered Node.js vulnerabilities.

Unauthorized or untrusted HTTP proxy deployments

• Built-in HTTP proxy support is intended for routing outbound requests through a proxy authorized by the deployment, for example because a firewall requires one to reach external networks. It is not an anonymity, traffic-hiding, or policy-evasion feature.
• Reports that depend on using an unauthorized proxy, expecting Node.js to provide privacy from a configured proxy or internal network, or expecting Node.js to enforce deployment-specific network policy or legal requirements are not considered Node.js vulnerabilities. Deployment operators are responsible for hardening such environments and controlling which proxy settings are allowed.

Malicious Third-Party Modules (CWE-1357)

• Code is trusted by Node.js. Therefore any scenario that requires a malicious third-party module cannot result in a vulnerability in Node.js.

Same-process self-harm

• Node.js trusts the code it is asked to run. A defect that can only be triggered by JavaScript, WASM, native, addon, FFI, or dependency code already executing in the target process is not a Node.js vulnerability merely because that code can crash, corrupt, or confuse the process it already controls. This includes forging an internal handle, reflecting or overwriting an internal Symbol(), installing a Symbol.hasInstance hook, or reaching into an internal binding.
• Such issues may still be fixed as common bugs. They become vulnerabilities only if the same defect is reachable from an element Node.js does not trust without relying on an application-created boundary.

Prototype Pollution Attacks (CWE-1321)

• 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.

Uncontrolled Search Path Element (CWE-427)

• 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.

External Control of System or Configuration Setting (CWE-15)

• If Node.js automatically loads a configuration file that is documented, no scenario that requires modification of that configuration file is considered a vulnerability.

Uncontrolled Resource Consumption (CWE-400) on outbound connections

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

Vulnerabilities affecting software downloaded by Corepack

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

Exposing Application-Level APIs to Untrusted Users (CWE-653)

• Node.js trusts the application code that uses its APIs. When application code exposes Node.js functionality to untrusted users in an unsafe manner, any resulting crashes, data corruption, or other issues are not considered vulnerabilities in Node.js itself. It is the application’s responsibility to:

  • Validate and sanitize all untrusted input before passing it to Node.js APIs.
  • Design appropriate access controls and security boundaries.
  • Avoid exposing low-level or dangerous APIs directly to untrusted users.

• Examples of scenarios that are not Node.js vulnerabilities:

  • Allowing untrusted users to register SQLite user-defined functions via node:sqlite (Database) that can perform arbitrary operations (e.g., closing database connections during query execution, causing crashes or use-after-free conditions).
  • Loading SQLite extensions using the allowExtension option in Database — this option must be explicitly set to true by the application, and enabling it is the application operator’s responsibility.
  • Using node:sqlite built-in SQL functions or pragmas (e.g., ATTACH DATABASE) to read or write files — Database operates with the same file-system access as the process itself, and it is the application’s responsibility to restrict what SQL is executed.
  • Exposing child_process.exec() or similar APIs to untrusted users without proper input validation, allowing command injection.
  • Allowing untrusted users to control file paths passed to file system APIs without validation, leading to path traversal issues.
  • Permitting untrusted users to define custom code that executes with the application’s privileges (e.g., custom transforms, plugins, or callbacks).

• These scenarios represent application-level security issues, not Node.js vulnerabilities. The root cause is the application’s failure to establish proper security boundaries between trusted application logic and untrusted user input.

Build System Attacks Requiring Control of the Build Environment (CWE-78, CWE-114, CWE-276)

• The Node.js build system (e.g., configure, configure.py, Makefile, vcbuild.bat) is designed to run in a trusted build environment. The build environment, including environment variables, the file system, and locally installed tools, is a trusted element in the Node.js threat model.
• Reports about command injection via environment variables in build scripts (e.g., CC, CXX, PKG_CONFIG, RUSTC), path hijacking in build output directories, or file permissions of build artifacts are not considered vulnerabilities. These scenarios require the attacker to already have control over the build environment, which means the system is already compromised.
• Build scripts are not a security boundary. They are expected to execute tools and scripts specified by the environment, and to trust the file system they operate on.

Unhandled ’error’ Events on EventEmitters (CWE-248)

• EventEmitters that can emit 'error' events require the application to attach an 'error' event handler. This includes HTTP streams and other Node.js core streams. If the application fails to attach an 'error' handler, the EventEmitter will throw an uncaught exception, which may crash the process.
• Crashes resulting from missing 'error' handlers are not considered denial-of-service vulnerabilities in Node.js. It is the application’s responsibility to properly handle errors by attaching appropriate 'error' event listeners to EventEmitters that may emit errors.

Exceptions Thrown by Application Callbacks (CWE-248)

• Node.js trusts the application code it is asked to run, including callbacks that are invoked by Node.js APIs. If an application callback throws an uncaught exception, any resulting crash is not considered a vulnerability in Node.js.
• For example, CVE-2026-21637 was triaged as a Node.js vulnerability, but scenarios that require TLS callbacks such as ALPNCallback, SNICallback, or pskCallback to throw are outside the Node.js threat model. Future reports of similar issues, where the crash depends on application callbacks throwing uncaught exceptions, will not be treated as Node.js vulnerabilities. It is the application’s responsibility to handle unexpected callback input and report errors without throwing uncaught exceptions.

Permission Model Boundaries (--permission)

The Node.js Permission Model (--permission) is an opt-in mechanism that limits which resources a Node.js process may access. It is designed to reduce the blast radius of mistakes in trusted application code, not to act as a security boundary against intentional misuse or a compromised process.

Permission Model reports are triaged in three lanes:

• Vulnerability: An element Node.js does not trust crosses a Node.js-owned permission check without trusted code already executing in the protected process.
• Security-interest bug: Trusted application code uses documented, stable APIs as intended, but Node.js fails to enforce a documented permission invariant consistently — for example, one API enforces a check that an equivalent API omits. These are fixed as hardening and are not automatically CVE-class, because the Permission Model is not a sandbox against malicious same-process code.
• Excluded: Intentional misuse by code already running in the process, operator-selected flags, a modified execArgv/env, or any expectation that the Permission Model sandboxes malicious same-process code.

The following are not vulnerabilities in Node.js:

• Operator-controlled flags: Behavior unlocked by flags the operator explicitly passes (e.g., --localstorage-file) is the operator’s responsibility. The permission model does not restrict how Node.js behaves when the operator intentionally configures it. This includes any file or resource that Node.js itself creates, writes, or reads at a location the operator selected through a flag, including every path derived from a template or pattern in that flag. For example, trace files rotated by --trace-event-file-pattern (${rotation}) being written without a matching --allow-fs-write entry is not a permission model bypass. Such paths are part of the operator’s configuration, not application file-system access. Inconsistent checks on these paths are treated as regular bugs and should be reported through the public issue tracker.

• node:sqlite and the permission model: Database operates with the same file-system privileges as the process. Using SQL pragmas or built-in SQLite mechanisms (e.g., ATTACH DATABASE) to access files does not bypass the permission model — the permission model does not intercept SQL-level file operations.

• Path resolution and symlinks: fs.realpathSync(), fs.realpath(), and similar functions resolve a path to its canonical form before the permission check is applied. Accessing a file through a symlink that resolves to an allowed path is the intended behavior, not a bypass. TOCTOU races on symlinks that resolve within the allowed list are similarly not considered permission model bypasses.

• worker_threads and the permission model: Creating a worker is gated by --allow-worker. A worker started with a modified execArgv or env may start without inheriting the parent’s permission configuration, so the permission model does not reliably propagate to such workers. Because worker creation already requires --allow-worker, and the Permission Model is not a sandbox against intentional misuse by trusted code, this is not considered a vulnerability. Applications that rely on the Permission Model must not grant --allow-worker to code they do not trust.

QUIC and HTTP/3

The experimental QUIC and HTTP/3 implementation in Node.js is a complex new protocol stack and API that is still under active development and should not be used for production workloads. Reports that only affect QUIC or HTTP/3 are not considered Node.js vulnerabilities at this time. It is expected that the QUIC and HTTP/3 implementation will continue to evolve, and security issues will be addressed as the implementation matures.

Virtual File System (node:vfs)

The experimental Virtual File System (node:vfs) is a virtualized file-system API for tests, fixtures, embedded assets, and application-managed storage. It is not a sandbox, permission system, or security boundary for untrusted code.

Code that can load node:vfs, receive a VirtualFileSystem instance, install a mount, choose a provider, or pass paths to VFS APIs is trusted application code. A VFS mount only redirects matching file-system calls; it does not hide or restrict access to the host file system. RealFSProvider root checks and read-only providers are implementation behavior, not security guarantees.

Reports that rely on using VFS to isolate untrusted JavaScript, native code, or user-controlled paths are not considered Node.js vulnerabilities. Use OS-level isolation, such as separate users, containers, or platform sandboxes, when a security boundary is required.

V8 Sandbox

The V8 sandbox is an in-process isolation mechanism internal to V8 that is not a Node.js security boundary. Node.js does not guarantee or document the V8 sandbox as a security feature, and it is not enabled in a way that provides security guarantees in production Node.js builds. Reports about escaping the V8 sandbox are not considered Node.js vulnerabilities; they should be reported directly to the V8 project.

CRLF Injection in writeEarlyHints()

ServerResponse.writeEarlyHints() accepts a link header value that is set by the application. Passing arbitrary strings, including CRLF sequences, as the link value is an application-level misuse of the API, not a Node.js vulnerability. Node.js validates the structure of Early Hints per the HTTP spec but does not sanitize free-form application data passed to it; that is the application’s responsibility.

Receiving security updates

Security notifications will be distributed via the following methods.

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

CVE publication timeline

When security releases are published, there is a built-in delay before the corresponding CVEs are publicly disclosed. This delay occurs because:

1. After the security release, we request the vulnerability reporter to disclose the details on HackerOne.
2. If the reporter does not disclose within one day, we proceed with forced disclosure to publish the CVEs.
3. The disclosure then goes through HackerOne’s approval process before the CVEs become publicly available.

As a result, CVEs may not be immediately available when security releases are published, but will typically be disclosed within a few days of the release.

Comments on this policy

If you have suggestions on how this process could be improved, please visit the nodejs/security-wggithub repository.

Incident Response Plan

In the event of a security incident, please refer to the Security Incident Response Plangithub.

Node.js Security Team

Node.js security team members are expected to keep all information that they have privileged access to by being on the team completely private to the team. This includes agreeing to not notify anyone outside the team of issues that have not yet been disclosed publicly, including the existence of issues, expectations of upcoming releases, and patching of any issues other than in the process of their work as a member of the security team.

Node.js Security Team Membership Policy

The Node.js Security Team has access to security-sensitive issues and patches that aren’t appropriate for public availability.

The policy for inclusion is as follows:

1. All members of @nodejs/TSC have access to private security reports and private patches.
2. Members of the @nodejs/releasers team have access to private security patches in order to produce releases.
3. On a case-by-case basis, individuals outside the Technical Steering Committee are invited by the TSC to have access to private security reports or private patches so that their expertise can be applied to an issue or patch. This access may be temporary or permanent, as decided by the TSC.

Membership on the security teams can be requested via an issue in the TSC repo.

Team responsible for Triaging security reports

The responsibility of Triage is to determine whether Node.js must take any action to mitigate the issue, and if so, to ensure that the action is taken.

Mitigation may take many forms, for example, a Node.js security release that includes a fix, documentation, an informational CVE or blog post.

• @mcollina - Matteo Collina
• @RafaelGSS - Rafael Gonzaga
• @vdeturckheim - Vladimir de Turckheim
• @BethGriggs - Beth Griggs

Team with access to private security reports against Node.js

TSC voting membersgithub have access.

In addition, these individuals have access:

• BethGriggs - Beth Griggs
• MylesBorins - Myles Borins
• bengl- Bryan English
• bnoordhuis Ben Noordhuis
• cjihrig Colin Ihrig
• joesepi - Joe Sepi
• juanarbol Juan Jose Arboleda
• sxa - Stewart X Addison
• ulisesgascon Ulises Gascón
• vdeturckheim - Vladimir de Turckheim

The list is from the member page for the Node.js program on HackerOne.

Team with access to private security patches to Node.js

• @aduh95 - Antoine du Hamel
• @anonrig - Yagiz Nizipli
• @bengl - Bryan English
• @benjamingr - Benjamin Gruenbaum
• @BethGriggs - Beth Griggs
• @bmeck - Bradley Farias
• @bnoordhuis - Ben Noordhuis
• @BridgeAR - Ruben Bridgewater
• @gireeshpunathil - Gireesh Punathil
• @guybedford - Guy Bedford
• @indutny - Fedor Indutny
• @jasnell - James M Snell
• @joaocgreis - João Reis
• @joesepi - Joe Sepi
• @joyeecheung - Joyee Cheung
• @juanarbol - Juan José
• @legendecas - Chengzhong Wu
• @marco-ippolito - Marco Ippolito
• @mcollina - Matteo Collina
• @MoLow - Moshe Atlow
• @panva - Filip Skokan
• @RafaelGSS - Rafael Gonzaga
• @richardlau - Richard Lau
• @ronag - Robert Nagy
• @ruyadorno - Ruy Adorno
• @santigimeno - Santiago Gimeno
• @ShogunPanda - Paolo Insogna
• @sxa - Stewart X Addison
• @targos - Michaël Zasso
• @tniessen - Tobias Nießen
• @UlisesGascon - Ulises Gascón
• @vdeturckheim - Vladimir de Turckheim