@@ -152,28 +152,33 @@ does not trust is considered a vulnerability: |
152 | 152 | the correct use of Node.js APIs. |
153 | 153 | * The unavailability of the runtime, including the unbounded degradation of its |
154 | 154 | performance. |
155 | | -* Memory leaks qualify as vulnerabilities when all of the following criteria are met: |
156 | | - * The API is being correctly used. |
157 | | - * The API doesn't have a warning against its usage in a production environment. |
158 | | - * The API is public and documented. |
159 | | - * The API is on stable (2.0) status. |
160 | | - * The memory leak is significant enough to cause a denial of service quickly |
161 | | - or in a context not controlled by the user (for example, HTTP parsing). |
162 | | - * The memory leak is directly exploitable by an untrusted source without requiring application mistakes. |
163 | | - * The leak cannot be reasonably mitigated through standard operational practices (like process recycling). |
164 | | - * The leak occurs deterministically under normal usage patterns rather than edge cases. |
165 | | - * The leak occurs at a rate that would cause practical resource exhaustion within a practical timeframe under |
166 | | - typical workloads. |
167 | | - * The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html), |
168 | | - where the attacker expends significantly fewer resources than what's required by the server to process the |
169 | | - attack. Attacks requiring comparable resources on the attacker's side (which can be mitigated through common |
170 | | - practices like rate limiting) may not qualify. |
171 | 155 |
|
172 | 156 | If Node.js loads configuration files or runs code by default (without a |
173 | 157 | specific request from the user), and this is not documented, it is considered a |
174 | 158 | vulnerability. |
175 | 159 | Vulnerabilities related to this case may be fixed by a documentation update. |
176 | 160 |
|
| 161 | +#### Denial of Service (DoS) vulnerabilities |
| 162 | + |
| 163 | +For a behavior to be considered a DoS vulnerability, the PoC must meet the following criteria: |
| 164 | + |
| 165 | +* The API is being correctly used. |
| 166 | +* The API doesn't have a warning against its usage in a production environment. |
| 167 | +* The API is public and documented. If the API comes from JavaScript, the behavior must be |
| 168 | + well-defined in the [ECMAScript specification](https://tc39.es/ecma262/). |
| 169 | +* The API has stable (2.0) status. |
| 170 | +* The behavior is significant enough to cause a denial of service quickly |
| 171 | + or in a context not controlled by the Node.js application developer (for example, HTTP parsing). |
| 172 | +* The behavior is directly exploitable by an untrusted source without requiring application mistakes. |
| 173 | +* The behavior cannot be reasonably mitigated through standard operational practices (like process recycling). |
| 174 | +* The behavior occurs deterministically under normal usage patterns rather than edge cases. |
| 175 | +* The behavior occurs at a rate that would cause practical resource exhaustion within a practical timeframe under |
| 176 | + typical workloads. |
| 177 | +* The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html), |
| 178 | + where the attacker expends significantly fewer resources than what's required by the server to process the |
| 179 | + attack. Attacks requiring comparable resources on the attacker's side (which can be mitigated through common |
| 180 | + practices like rate limiting) may not qualify. |
| 181 | + |
177 | 182 | **Node.js does NOT trust**: |
178 | 183 |
|
179 | 184 | * Data received from the remote end of inbound network connections |
|