Skip to content

doc: add constraints for mem leak to threat model #58917

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

doc: add constraints for mem leak to threat model #58917

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
666abb3
doc: add constraints for mem leak to threat model
RafaelGSS Jul 1, 2025
b3b9bbc
fixup! doc: add constraints for mem leak to threat model
RafaelGSS Jul 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,17 @@ does not trust is considered a vulnerability:
the correct use of Node.js APIs.
* The unavailability of the runtime, including the unbounded degradation of its
performance.
* Memory leaks qualify as vulnerabilities when all of the following criteria are met:
* 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
* The API is on stable (2.0) status
* The memory leak is significant, causing a DoS fast or in a user-uncontrolled space (for instance, on HTTP parsing)
Copy link
Member

@joyeecheung joyeecheung Jul 1, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that we still need more restrictions to avoid flagging all the existing memory leaks as vulnerabilities just because they weren't reported as vulnerabilities (for example, #54614 probably satisfies all the criteria and it can be used in server handlers). As long as a buggy API is used in the wrong place, it can cause a DoS fast, and it doesn't have to be a memory leak, so it seems to be a very slippery slope.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would b3b9bbc satisfies that?

* The memory leak is directly exploitable by an untrusted source without requiring application mistakes
* The leak cannot be reasonably mitigated through standard operational practices (like process recycling)
* The leak occurs deterministically under normal usage patterns rather than edge cases
* The leak occurs at a rate that would cause practical resource exhaustion within X requests or Y hours under
typical workloads

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
Expand Down
Loading