@@ -109,6 +109,21 @@ does not trust is considered a vulnerability:
|
109 | 109 | the correct use of Node.js APIs. |
110 | 110 | * The unavailability of the runtime, including the unbounded degradation of its |
111 | 111 | performance. |
| 112 | +* Memory leaks qualify as vulnerabilities when all of the following criteria are met: |
| 113 | +* The API is being correctly used. |
| 114 | +* The API doesn't have a warning against its usage in a production environment. |
| 115 | +* The API is public and documented. |
| 116 | +* The API is on stable (2.0) status. |
| 117 | +* The memory leak is significant, causing a DoS fast or in a user-uncontrolled space (for instance, on HTTP parsing). |
| 118 | +* The memory leak is directly exploitable by an untrusted source without requiring application mistakes. |
| 119 | +* The leak cannot be reasonably mitigated through standard operational practices (like process recycling). |
| 120 | +* The leak occurs deterministically under normal usage patterns rather than edge cases. |
| 121 | +* The leak occurs at a rate that would cause practical resource exhaustion within a practical timeframe under |
| 122 | + typical workloads. |
| 123 | +* The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html), |
| 124 | + where the attacker expends significantly fewer resources than what's required by the server to process the |
| 125 | + attack. Attacks requiring comparable resources on the attacker's side (which can be mitigated through common |
| 126 | + practices like rate limiting) may not qualify. |
112 | 127 | |
113 | 128 | If Node.js loads configuration files or runs code by default (without a |
114 | 129 | specific request from the user), and this is not documented, it is considered a |
|