From efe4b44bc72752980fefa8ac187a6fc2de9498cf Mon Sep 17 00:00:00 2001 From: Matteo Collina Date: Tue, 16 Jun 2026 12:02:15 +0200 Subject: [PATCH] doc: clarify callback exceptions Signed-off-by: Matteo Collina --- SECURITY.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 55251f7da7993b..8444534c77bd15 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -374,6 +374,21 @@ the community they pose. responsibility to properly handle errors by attaching appropriate `'error'` event listeners to EventEmitters that may emit errors. +#### Exceptions Thrown by Application Callbacks (CWE-248) + +* Node.js trusts the application code it is asked to run, including callbacks + that are invoked by Node.js APIs. If an application callback throws an + uncaught exception, any resulting crash is not considered a vulnerability in + Node.js. +* For example, [CVE-2026-21637](https://www.cve.org/CVERecord?id=CVE-2026-21637) + was triaged as a Node.js vulnerability, but scenarios that require TLS + callbacks such as `ALPNCallback`, `SNICallback`, or `pskCallback` to throw + are outside the Node.js threat model. Future reports of similar issues, + where the crash depends on application callbacks throwing uncaught + exceptions, will not be treated as Node.js vulnerabilities. It is the + application's responsibility to handle unexpected callback input and report + errors without throwing uncaught exceptions. + #### Permission Model Boundaries (`--permission`) The Node.js [Permission Model](https://nodejs.org/api/permissions.html)