From 666abb33bf1be11d05c084dd0b42dc3fc1d99105 Mon Sep 17 00:00:00 2001 From: RafaelGSS Date: Tue, 1 Jul 2025 10:25:25 -0300 Subject: [PATCH 1/4] doc: add constraints for mem leak to threat model As discussed in https://github.com/nodejs-private/node-private/pull/719. We should clarify what the criteria are to accept memory leak as a vulnerability (potential DoS). Signed-off-by: RafaelGSS --- SECURITY.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 9650e812914f81..627bbfd6a56a77 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -109,6 +109,11 @@ 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 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) 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 From b3b9bbc4e449a13870bc8eca59d203092dddaed0 Mon Sep 17 00:00:00 2001 From: RafaelGSS Date: Mon, 7 Jul 2025 12:44:17 -0300 Subject: [PATCH 2/4] fixup! doc: add constraints for mem leak to threat model --- SECURITY.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 627bbfd6a56a77..1e2845f96c601f 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -112,8 +112,14 @@ does not trust is considered a vulnerability: * 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) + * 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 From 6da6f83fe1595f336e181dc50638e760f6e28cba Mon Sep 17 00:00:00 2001 From: RafaelGSS Date: Thu, 17 Jul 2025 16:30:24 -0300 Subject: [PATCH 3/4] fixup! fixup! doc: add constraints for mem leak to threat model --- SECURITY.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index 1e2845f96c601f..1c60c2fc593d76 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -118,8 +118,12 @@ does not trust is considered a vulnerability: * 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 + * The leak occurs at a rate that would cause practical resource exhaustion within a practical timeframe under typical workloads + * The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html), + 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 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 From 30a830c9db636af22f0ae9fc1630ae06e1693898 Mon Sep 17 00:00:00 2001 From: RafaelGSS Date: Wed, 23 Jul 2025 18:01:57 -0300 Subject: [PATCH 4/4] fixup! fixup! fixup! doc: add constraints for mem leak to threat model --- SECURITY.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 1c60c2fc593d76..89a592d743b03d 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -110,20 +110,20 @@ does not trust is considered a vulnerability: * 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) - * 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 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). + * 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 a practical timeframe under - typical workloads + typical workloads. * The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html), 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 + practices like rate limiting) may not qualify. 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