@@ -309,6 +309,32 @@ the community they pose.
309309 Node.js releases won't be affected by such vulnerabilities. Users are
310310 responsible for keeping the software they use through Corepack up-to-date.
311311
312+ #### Exposing Application-Level APIs to Untrusted Users (CWE-653)
313+
314+ * Node.js trusts the application code that uses its APIs. When application code
315+ exposes Node.js functionality to untrusted users in an unsafe manner, any
316+ resulting crashes, data corruption, or other issues are not considered
317+ vulnerabilities in Node.js itself. It is the application's responsibility to:
318+ * Validate and sanitize all untrusted input before passing it to Node.js APIs.
319+ * Design appropriate access controls and security boundaries.
320+ * Avoid exposing low-level or dangerous APIs directly to untrusted users.
321+
322+ * Examples of scenarios that are ** not** Node.js vulnerabilities:
323+ * Allowing untrusted users to register SQLite user-defined functions that can
324+ perform arbitrary operations (e.g., closing database connections during query
325+ execution, causing crashes or use-after-free conditions).
326+ * Exposing ` child_process.exec() ` or similar APIs to untrusted users without
327+ proper input validation, allowing command injection.
328+ * Allowing untrusted users to control file paths passed to filesystem APIs
329+ without validation, leading to path traversal issues.
330+ * Permitting untrusted users to define custom code that executes with the
331+ application's privileges (e.g., custom transforms, plugins, or callbacks).
332+
333+ * These scenarios represent application-level security issues, not Node.js
334+ vulnerabilities. The root cause is the application's failure to establish
335+ proper security boundaries between trusted application logic and untrusted
336+ user input.
337+
312338## Assessing experimental features reports
313339
314340Experimental features are eligible for security reports just like any other
0 commit comments