node-forge EUVD-2026-113336

Exploitation requires the victim application to use node-forge's TLS client specifically - forge.tls.createConnection({server:false}) - on a vulnerable version (<= 1.4.0), and to feed received network bytes into connection.process() from a handler that does not catch the thrown exception (the GHSA workaround is to wrap process() in try/catch and close the connection). The attacker must either be the TLS server the client connects to, or an on-path peer able to modify the still-unauthenticated handshake to drop the server Certificate message; no credentials are needed (PR:N). Limiting factors: applications that use Node.js's native TLS stack are NOT affected; only the forge TLS-client code path is vulnerable; and the attacker needs the client to connect to an attacker-controlled/on-path endpoint. Impact is limited to a crash (availability) - there is no confidentiality or integrity impact and no authentication bypass.

This is a moderate-severity denial-of-service (CWE-476 NULL pointer dereference) in the node-forge TLS *client*, and the signals are internally consistent at a middling priority rather than an emergency. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, 5.9) confirms network reach, no authentication (PR:N) and availability-only impact (C:N/I:N - the advisory explicitly states there is no confidentiality or integrity impact and no authentication bypass, since without a certificate the client cannot complete the RSA key exchange). The vuln.today Decision label is 'this_month', indicating a planned-remediation priority, not act_now/emergency. No CISA KEV entry is present, so this is 'no public exploit identified as actively exploited'; however the GHSA advisory includes a detailed Proof of concept and committed regression tests, so a public PoC reference exists - it is not supplied as verified standalone weaponized exploit code. No EPSS score was provided, so exploitation-probability cannot be quantified from this data; absence of EPSS is a gap, not a low score. The vendor's own 3.1 AC:H and the informational 4.0 vector (AC:L/AT:P, 8.2) diverge because 4.0 weights availability higher; I assess the trigger itself as low-complexity (a malicious server simply omits the Certificate message), with the real limiter being that a forge TLS client must connect to an attacker-controlled or on-path-modifiable endpoint - see my independent vector below. Net: a genuine, patch-worthy reliability/DoS bug with a narrow prerequisite (use of the forge TLS client), not a high-urgency RCE.

An application uses forge.tls.createConnection({server:false}) and connects to a server that is attacker-controlled, or an on-path attacker strips the Certificate (handshake type 11) message from an unauthenticated server's first flight. The client's missing-certificate check reads the wrong property (c.serverCertificate instead of c.session.serverCertificate), so the handshake proceeds to key exchange, dereferences the null certificate's publicKey, and throws an uncaught TypeError out of connection.process() - crashing the Node.js process. A detailed reproduction PoC and regression tests are published in the GHSA advisory.