Digitalbazaar
Monthly
Denial of service in node-forge (Forge) 1.3.2 through 1.4.0 lets remote, unauthenticated attackers exhaust CPU time and heap in any application that parses attacker-supplied DER or PEM through asn1.fromDer() with default options, aborting the Node.js process with a fatal out-of-memory error the application cannot catch. It is an incomplete fix of CVE-2025-66031: ASN.1 decoded from primitive BIT STRING contents bypasses the maxDepth recursion limit, and nested BIT STRINGs are decoded recursively while a deep copy of the decoded contents is retained at every level, so memory grows quadratically with nesting depth. Tens of kilobytes of crafted input reach hundreds of megabytes to gigabytes via pki.certificateFromPem(), pki.publicKeyFromPem(), the PKCS#7/#8/#12 loaders and forge's TLS client certificate parsing; no public exploit tooling is identified at time of analysis, although the upstream advisory documents a proof-of-concept input shape (nested BIT STRINGs) that is not verified as working exploit code, and 1.4.1 fixes the issue by propagating maxDepth into the BIT STRING decode and decoding only one level.
Certificate chain validation in node-forge (Forge) through version 1.4.0 can be bypassed because the parser maps the deprecated extension OIDs 2.5.29.10 and 2.5.29.13 to the same 'basicConstraints' name as the RFC 5280 OID 2.5.29.19, and forge.pki.verifyCertificateChain() looked the extension up by name, returning the first match. An attacker who obtains a certificate from a trusted CA that copies request extensions can prepend a forged deprecated-OID basicConstraints with cA TRUE ahead of the genuine cA FALSE extension, have the certificate treated as a CA, and then issue certificates for arbitrary names - enabling server or client impersonation in forge.tls and any application using the library's PKI verification. The flaw is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4 High), with the high attack complexity reflecting the reliance on a cooperating trusted CA; no CISA KEV entry is present in the provided data, but a proof-of-concept is published in the upstream repository's test suite (tests/pocs/ghsa-5x38-2vff-x55p.js).
Denial of service in node-forge's JavaScript TLS implementation: a connection created with forge.tls.createConnection() throws an uncaught TypeError from process() when a peer sends a record of a different content type (alert, change_cipher_spec, application_data or heartbeat) in the middle of a handshake message that was fragmented across records. Any peer with network reachability can trigger it unauthenticated with roughly 18 bytes before the handshake completes - in server mode any connecting client, in client mode any server the forge client talks to - and in Node.js deployments that follow the documented pattern of calling process() from a socket 'data' handler, the exception terminates the process, dropping every connection it serves and allowing repetition on each restart. There is no confidentiality or integrity impact, and forged traffic is limited to availability (CVSS 3.1 7.5, A:H); no confirmed active exploitation or KEV listing is reported, though the advisory itself publishes a two-record proof-of-concept byte sequence, which is not verified as working exploit code. Fixed in node-forge 1.4.1.
Call stack exhaustion in node-forge's TLS record processing (all versions through 1.4.0) allows a remote peer to crash or degrade applications that run forge.tls.createConnection() by sending a single chunk of thousands of tiny TLS records. Because heartbeat records are dispatched in every connection state, no authentication, valid handshake, or extension negotiation is needed - roughly 2,300 eight-byte records (under 20 KB) is enough on Node.js 24 because each record consumes another stack frame and eventually throws an uncaught RangeError. In Node.js applications wired to a socket 'data' handler, that exception terminates the whole process and drops every connection it serves, while browser-side use is limited to the single attacked connection; no confidentiality or integrity impact exists. A public proof-of-concept input (5,000 repeated heartbeat records) is documented in the vendor advisory, no CISA KEV entry or other active-exploitation reporting is present in the data, and the vendor fix is node-forge 1.4.1, which processes records iteratively.
PKCS#12 MAC forgery and constant-key password-based decryption in node-forge 1.4.0 and earlier let anyone who does not know a PFX password tamper with a PKCS#12 file - swapping in attacker-chosen certificates or an unencrypted private key - and have forge.pkcs12.pkcs12FromAsn1() report the MAC as verified under whatever password the application supplies. The root cause is that a MacData iteration count of zero or less is accepted from the input, collapsing the RFC 7292 Appendix B.2 key derivation to a public constant (0x03 repeated); the same KDF is used by the pbeWithSHAAnd3-KeyTripleDES-CBC and pbewithSHAAnd40BitRC2-CBC schemes, so shrouded key bags, encrypted SafeContents and PKCS#8 ENCRYPTED PRIVATE KEY input handled via forge.pki.decryptPrivateKeyInfo() likewise decrypt with any password. The vendor advisory ships a working proof-of-concept and the fix commit adds it to tests/pocs/; no CISA KEV listing exists and exploitation is limited to applications that import PKCS#12 or encrypted PKCS#8 material from untrusted parties and rely on MAC verification or successful decryption as proof of password knowledge. With CVSS 3.1 scored 7.5 (AV:N/AC:L/PR:N/UI:N, integrity-only impact) this is a genuine integrity bypass but not an emergency for deployments that only load their own trusted keystores; it should be remediated this week given the public PoC.
Regular expression denial of service in node-forge's pem.decode() allows remote, unauthenticated attackers to block the Node.js event loop for seconds to minutes by supplying crafted PEM text of a few tens of kilobytes to any high-level parser, including pki.certificateFromPem(), pki.privateKeyFromPem(), pki.certificationRequestFromPem() and pkcs7.messageFromPem(). All versions up to and including 1.4.0 are affected, and the flaw is rated CVSS 3.1 7.5 with availability-only impact (C:N/I:N/A:H). A public proof-of-concept is documented in the vendor advisory GHSA-7wch-p9px-956x, which reports roughly 24 seconds of blockage from a 29 KB input on version 1.4.0; no CISA KEV entry is indicated in the supplied intelligence, and the vuln.today priority is this_week.
RSA PKCS#1 v1.5 signature forgery in node-forge through v1.4.0 enables unauthenticated network attackers to craft signatures that pass verification against arbitrary messages when the verifying party uses low-exponent RSA keys (e=3). The root cause is missing element-count validation inside nested DigestAlgorithm ASN.1 sequences: forge's `_parseAllDigestBytes` mode confirms all bytes are consumed but does not enforce the canonical minimal DigestInfo shape required by RFC 8017, allowing garbage bytes inside the DigestAlgorithm container to survive verification while OpenSSL rejects the same structure. This is explicitly described as an incomplete fix for CVE-2026-33894; a working proof-of-concept is documented in the linked GHSA advisory; no public exploit identified in CISA KEV at time of analysis.
Certificate chain verification in node-forge (Forge) through 1.4.0 silently ignores a CA certificate's basicConstraints pathLenConstraint whenever that CA lacks a keyUsage extension, so chains that exceed the declared path length still pass forge.pki.verifyCertificateChain(). Remote attackers are the relevant threat model (CVSS:3.1/AV:N/AC:H/PR:N/UI:N, 5.9 Moderate, CWE-295), but exploitation is heavily gated: the attacker must already hold the private key of a path-length-constrained CA that chains to an application-trusted root, or have obtained a CA certificate from it, and public web PKI CAs normally include keyUsage, so exposure is concentrated in private PKIs whose CA certificates were issued without it. The upstream advisory ships a public PoC reference (tests/pocs/ghsa-h46v-rmh6-fq4f.js) demonstrating that a pathLenConstraint=0 intermediate without keyUsage is accepted; that PoC is not verified as working exploit code and there is no public exploit identified at time of analysis, and no confirmed active exploitation (CISA KEV). Fixed in node-forge 1.4.1.
AES-GCM authentication bypass in node-forge (digitalbazaar) versions up to and including 1.4.0: when an application passes a zero-like tagLength (0, null, false, '', or '0') to forge.cipher.createDecipher('AES-GCM') and the supplied authentication tag is empty or missing, decipher.finish() returns true for arbitrary attacker-chosen ciphertext, so forged or modified messages are accepted as authentic. Exploitation is conditional - it requires the application to derive tagLength from received data (for example receivedTag.length * 8 for an empty tag) or to leave it as an unset/zero configuration value; applications that omit tagLength (128-bit default) or pass a fixed valid NIST tag length are not affected. The flaw is integrity-only (C:N/I:H/A:N, CVSS 3.1 5.9 with AC:H) and a public PoC reference exists in the GHSA advisory showing the tagLength: 0 / empty-tag construction; no confirmed active exploitation (CISA KEV) or working exploit code was identified at time of analysis.
Node-forge versions through 1.4.0 hang indefinitely at 100% CPU when BigInteger.prototype.modInverse() receives a negative value or negative modulus, and in forge this is reachable by passing a negative RSA public exponent e to forge.pki.rsa.generateKeyPair() or the stateful key-generation APIs. The flaw is an incomplete fix of CVE-2026-33891, which only guarded against a zero operand; only applications that forward untrusted input as the RSA exponent, or call modInverse() directly with negative operands, are affected, while keys parsed from DER, PEM, JWK, PKCS#12, X.509 and TLS are unsigned and cannot trigger it. No public exploit code or active exploitation is identified, the vendor rates it Low (CVSS 3.1: 2.9), and a documented proof of concept shows a single call blocking the Node.js event loop; version 1.4.1 resolves it.
Certificate chain verification in node-forge (Forge) before 1.4.1 can permanently delete trusted CA certificates from a reused pki.createCaStore() store when two or more of those certificates share a subject name, so a remote peer that sends any certificate naming that shared subject as its issuer can cause every later validation against those CAs to fail until the store is recreated. Only applications that keep one long-lived store containing duplicate-subject CA certificates and reuse it across pki.verifyCertificateChain() calls are exposed - chiefly private PKIs with re-keyed, renewed or cross-signed roots - and no invalid chain is ever accepted, so this is a persistent availability impact confined to those specific CAs. The flaw is fixed in 1.4.1, a public proof-of-concept is included in the vendor advisory, and the vendor rates it Low (CVSS 3.1: 3.7); there is no confirmation of active exploitation and the priority signal is monitor.
Denial of service in node-forge's TLS client (1.4.0 and earlier) lets a malicious TLS server, or an on-path attacker who strips the server Certificate message, crash applications that call forge.tls.createConnection({server:false}). The client's missing-certificate check reads the wrong property, so the handshake proceeds into RSA key exchange and dereferences the absent certificate, throwing a TypeError out of connection.process() that can terminate a Node.js process when uncaught. The flaw is availability-only (assessed CVSS 3.1: 5.9, AV:N/AC:L/PR:N/UI:N, C:N/I:N/A:H), is not in CISA KEV, and has a public PoC reference in the advisory that is not verified as working exploit code; applications using Node.js's native TLS stack are unaffected.
Prototype pollution in the forge.http cookie store in node-forge through 1.4.0 lets a malicious server write attacker-controlled properties onto Object.prototype or the Object constructor, and delete built-in Object.prototype methods, in any application that uses forge.http directly or forge.xhr from the forge.all browser bundle. Only unauthenticated remote interaction is required in the CVSS vector (AV:N/PR:N/UI:N) but the vector also carries AC:H, reflecting that the attacker must control or influence the server the client connects to and the application must actually load forge.http; crucially forge.http is not loaded by require('node-forge'), so ordinary Node.js TLS/crypto consumers are unaffected. Its impact is confined to the JavaScript realm's object model (C:N/I:L/A:L, CVSS 3.1 base 4.8), and no public exploit code or active exploitation is identified in the available data; node-forge 1.4.1 fixes the issue.
CBC and ECB decryption in node-forge 1.4.0 and earlier accepts malformed PKCS#7 padding, so an application that treats a successful decipher.finish() as proof of valid data can accept tampered ciphertext with up to four blocks of trailing plaintext silently removed. Affected are npm users of the digitalbazaar/forge package who decrypt attacker-influenced data in CBC or ECB mode, including PKCS#7 EncryptedData/EnvelopedData, PKCS#12 and encrypted private keys; impact is integrity-only (CVSS 3.1 3.7, AC:H, no confidentiality or availability effect) because CBC/ECB without a MAC are already malleable. The flaw is fixed in 1.4.1, and the vendor advisory publishes a short proof-of-concept decrypt snippet showing a Wycheproof invalid vector returning true on 1.4.0 and false on 1.4.1; it demonstrates the padding acceptance but gives no remote attack path, so no active exploitation is indicated by the available data.
OID-based authorization bypass in node-forge through 1.4.0: asn1.oidToDer() fails to range-check the first two arcs of an OID string, so input such as 0.42.840.113549.1.1.1 is encoded as the DER of rsaEncryption (1.2.840.113549.1.1.1). This affects only applications that accept an OID string from untrusted input, check or authorize that string, and then re-encode it with node-forge when building certificates, CSRs or other ASN.1 structures; DER parsing is unaffected and there is no confidentiality or availability impact. node-forge 1.4.1 fixes the truncation, a public PoC reference exists in the GHSA (not verified as working exploit code), and this is a genuinely low-priority issue despite being worth patching (vuln.today: monitor).
Certificate chain verification in node-forge 1.4.0 and earlier chooses the RSA padding scheme and RSASSA-PSS parameters from the issuer certificate rather than from the child certificate being verified, so a certificate whose signatureAlgorithm fields are labeled RSASSA-PSS is accepted on a PKCS#1 v1.5 signature when the trusted issuer was itself PKCS#1 v1.5-signed. The practical impact is confined to applications that treat a certificate's declared signature scheme as a trust decision - the signature must still be produced with the trusted issuer's private key, so certificate identity cannot be forged, and there is no confidentiality or availability impact. Rated 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N), unauthenticated from the network, with no KEV listing or confirmed working exploit code reported; the vendor advisory does include a public proof-of-concept reproduction procedure, and node-forge 1.4.1 fixes the flaw, so this is a monitor-priority item rather than an emergency.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severity (CVSS 8.7), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Integer Overflow vulnerability could allow attackers to cause unexpected behavior through arithmetic overflow.
An interpretation-conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and earlier enables unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a. Rated high severity (CVSS 8.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
The package node-forge before 0.10.0 is vulnerable to Prototype Pollution via the util.setPath function. Rated high severity (CVSS 7.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Denial of service in node-forge (Forge) 1.3.2 through 1.4.0 lets remote, unauthenticated attackers exhaust CPU time and heap in any application that parses attacker-supplied DER or PEM through asn1.fromDer() with default options, aborting the Node.js process with a fatal out-of-memory error the application cannot catch. It is an incomplete fix of CVE-2025-66031: ASN.1 decoded from primitive BIT STRING contents bypasses the maxDepth recursion limit, and nested BIT STRINGs are decoded recursively while a deep copy of the decoded contents is retained at every level, so memory grows quadratically with nesting depth. Tens of kilobytes of crafted input reach hundreds of megabytes to gigabytes via pki.certificateFromPem(), pki.publicKeyFromPem(), the PKCS#7/#8/#12 loaders and forge's TLS client certificate parsing; no public exploit tooling is identified at time of analysis, although the upstream advisory documents a proof-of-concept input shape (nested BIT STRINGs) that is not verified as working exploit code, and 1.4.1 fixes the issue by propagating maxDepth into the BIT STRING decode and decoding only one level.
Certificate chain validation in node-forge (Forge) through version 1.4.0 can be bypassed because the parser maps the deprecated extension OIDs 2.5.29.10 and 2.5.29.13 to the same 'basicConstraints' name as the RFC 5280 OID 2.5.29.19, and forge.pki.verifyCertificateChain() looked the extension up by name, returning the first match. An attacker who obtains a certificate from a trusted CA that copies request extensions can prepend a forged deprecated-OID basicConstraints with cA TRUE ahead of the genuine cA FALSE extension, have the certificate treated as a CA, and then issue certificates for arbitrary names - enabling server or client impersonation in forge.tls and any application using the library's PKI verification. The flaw is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4 High), with the high attack complexity reflecting the reliance on a cooperating trusted CA; no CISA KEV entry is present in the provided data, but a proof-of-concept is published in the upstream repository's test suite (tests/pocs/ghsa-5x38-2vff-x55p.js).
Denial of service in node-forge's JavaScript TLS implementation: a connection created with forge.tls.createConnection() throws an uncaught TypeError from process() when a peer sends a record of a different content type (alert, change_cipher_spec, application_data or heartbeat) in the middle of a handshake message that was fragmented across records. Any peer with network reachability can trigger it unauthenticated with roughly 18 bytes before the handshake completes - in server mode any connecting client, in client mode any server the forge client talks to - and in Node.js deployments that follow the documented pattern of calling process() from a socket 'data' handler, the exception terminates the process, dropping every connection it serves and allowing repetition on each restart. There is no confidentiality or integrity impact, and forged traffic is limited to availability (CVSS 3.1 7.5, A:H); no confirmed active exploitation or KEV listing is reported, though the advisory itself publishes a two-record proof-of-concept byte sequence, which is not verified as working exploit code. Fixed in node-forge 1.4.1.
Call stack exhaustion in node-forge's TLS record processing (all versions through 1.4.0) allows a remote peer to crash or degrade applications that run forge.tls.createConnection() by sending a single chunk of thousands of tiny TLS records. Because heartbeat records are dispatched in every connection state, no authentication, valid handshake, or extension negotiation is needed - roughly 2,300 eight-byte records (under 20 KB) is enough on Node.js 24 because each record consumes another stack frame and eventually throws an uncaught RangeError. In Node.js applications wired to a socket 'data' handler, that exception terminates the whole process and drops every connection it serves, while browser-side use is limited to the single attacked connection; no confidentiality or integrity impact exists. A public proof-of-concept input (5,000 repeated heartbeat records) is documented in the vendor advisory, no CISA KEV entry or other active-exploitation reporting is present in the data, and the vendor fix is node-forge 1.4.1, which processes records iteratively.
PKCS#12 MAC forgery and constant-key password-based decryption in node-forge 1.4.0 and earlier let anyone who does not know a PFX password tamper with a PKCS#12 file - swapping in attacker-chosen certificates or an unencrypted private key - and have forge.pkcs12.pkcs12FromAsn1() report the MAC as verified under whatever password the application supplies. The root cause is that a MacData iteration count of zero or less is accepted from the input, collapsing the RFC 7292 Appendix B.2 key derivation to a public constant (0x03 repeated); the same KDF is used by the pbeWithSHAAnd3-KeyTripleDES-CBC and pbewithSHAAnd40BitRC2-CBC schemes, so shrouded key bags, encrypted SafeContents and PKCS#8 ENCRYPTED PRIVATE KEY input handled via forge.pki.decryptPrivateKeyInfo() likewise decrypt with any password. The vendor advisory ships a working proof-of-concept and the fix commit adds it to tests/pocs/; no CISA KEV listing exists and exploitation is limited to applications that import PKCS#12 or encrypted PKCS#8 material from untrusted parties and rely on MAC verification or successful decryption as proof of password knowledge. With CVSS 3.1 scored 7.5 (AV:N/AC:L/PR:N/UI:N, integrity-only impact) this is a genuine integrity bypass but not an emergency for deployments that only load their own trusted keystores; it should be remediated this week given the public PoC.
Regular expression denial of service in node-forge's pem.decode() allows remote, unauthenticated attackers to block the Node.js event loop for seconds to minutes by supplying crafted PEM text of a few tens of kilobytes to any high-level parser, including pki.certificateFromPem(), pki.privateKeyFromPem(), pki.certificationRequestFromPem() and pkcs7.messageFromPem(). All versions up to and including 1.4.0 are affected, and the flaw is rated CVSS 3.1 7.5 with availability-only impact (C:N/I:N/A:H). A public proof-of-concept is documented in the vendor advisory GHSA-7wch-p9px-956x, which reports roughly 24 seconds of blockage from a 29 KB input on version 1.4.0; no CISA KEV entry is indicated in the supplied intelligence, and the vuln.today priority is this_week.
RSA PKCS#1 v1.5 signature forgery in node-forge through v1.4.0 enables unauthenticated network attackers to craft signatures that pass verification against arbitrary messages when the verifying party uses low-exponent RSA keys (e=3). The root cause is missing element-count validation inside nested DigestAlgorithm ASN.1 sequences: forge's `_parseAllDigestBytes` mode confirms all bytes are consumed but does not enforce the canonical minimal DigestInfo shape required by RFC 8017, allowing garbage bytes inside the DigestAlgorithm container to survive verification while OpenSSL rejects the same structure. This is explicitly described as an incomplete fix for CVE-2026-33894; a working proof-of-concept is documented in the linked GHSA advisory; no public exploit identified in CISA KEV at time of analysis.
Certificate chain verification in node-forge (Forge) through 1.4.0 silently ignores a CA certificate's basicConstraints pathLenConstraint whenever that CA lacks a keyUsage extension, so chains that exceed the declared path length still pass forge.pki.verifyCertificateChain(). Remote attackers are the relevant threat model (CVSS:3.1/AV:N/AC:H/PR:N/UI:N, 5.9 Moderate, CWE-295), but exploitation is heavily gated: the attacker must already hold the private key of a path-length-constrained CA that chains to an application-trusted root, or have obtained a CA certificate from it, and public web PKI CAs normally include keyUsage, so exposure is concentrated in private PKIs whose CA certificates were issued without it. The upstream advisory ships a public PoC reference (tests/pocs/ghsa-h46v-rmh6-fq4f.js) demonstrating that a pathLenConstraint=0 intermediate without keyUsage is accepted; that PoC is not verified as working exploit code and there is no public exploit identified at time of analysis, and no confirmed active exploitation (CISA KEV). Fixed in node-forge 1.4.1.
AES-GCM authentication bypass in node-forge (digitalbazaar) versions up to and including 1.4.0: when an application passes a zero-like tagLength (0, null, false, '', or '0') to forge.cipher.createDecipher('AES-GCM') and the supplied authentication tag is empty or missing, decipher.finish() returns true for arbitrary attacker-chosen ciphertext, so forged or modified messages are accepted as authentic. Exploitation is conditional - it requires the application to derive tagLength from received data (for example receivedTag.length * 8 for an empty tag) or to leave it as an unset/zero configuration value; applications that omit tagLength (128-bit default) or pass a fixed valid NIST tag length are not affected. The flaw is integrity-only (C:N/I:H/A:N, CVSS 3.1 5.9 with AC:H) and a public PoC reference exists in the GHSA advisory showing the tagLength: 0 / empty-tag construction; no confirmed active exploitation (CISA KEV) or working exploit code was identified at time of analysis.
Node-forge versions through 1.4.0 hang indefinitely at 100% CPU when BigInteger.prototype.modInverse() receives a negative value or negative modulus, and in forge this is reachable by passing a negative RSA public exponent e to forge.pki.rsa.generateKeyPair() or the stateful key-generation APIs. The flaw is an incomplete fix of CVE-2026-33891, which only guarded against a zero operand; only applications that forward untrusted input as the RSA exponent, or call modInverse() directly with negative operands, are affected, while keys parsed from DER, PEM, JWK, PKCS#12, X.509 and TLS are unsigned and cannot trigger it. No public exploit code or active exploitation is identified, the vendor rates it Low (CVSS 3.1: 2.9), and a documented proof of concept shows a single call blocking the Node.js event loop; version 1.4.1 resolves it.
Certificate chain verification in node-forge (Forge) before 1.4.1 can permanently delete trusted CA certificates from a reused pki.createCaStore() store when two or more of those certificates share a subject name, so a remote peer that sends any certificate naming that shared subject as its issuer can cause every later validation against those CAs to fail until the store is recreated. Only applications that keep one long-lived store containing duplicate-subject CA certificates and reuse it across pki.verifyCertificateChain() calls are exposed - chiefly private PKIs with re-keyed, renewed or cross-signed roots - and no invalid chain is ever accepted, so this is a persistent availability impact confined to those specific CAs. The flaw is fixed in 1.4.1, a public proof-of-concept is included in the vendor advisory, and the vendor rates it Low (CVSS 3.1: 3.7); there is no confirmation of active exploitation and the priority signal is monitor.
Denial of service in node-forge's TLS client (1.4.0 and earlier) lets a malicious TLS server, or an on-path attacker who strips the server Certificate message, crash applications that call forge.tls.createConnection({server:false}). The client's missing-certificate check reads the wrong property, so the handshake proceeds into RSA key exchange and dereferences the absent certificate, throwing a TypeError out of connection.process() that can terminate a Node.js process when uncaught. The flaw is availability-only (assessed CVSS 3.1: 5.9, AV:N/AC:L/PR:N/UI:N, C:N/I:N/A:H), is not in CISA KEV, and has a public PoC reference in the advisory that is not verified as working exploit code; applications using Node.js's native TLS stack are unaffected.
Prototype pollution in the forge.http cookie store in node-forge through 1.4.0 lets a malicious server write attacker-controlled properties onto Object.prototype or the Object constructor, and delete built-in Object.prototype methods, in any application that uses forge.http directly or forge.xhr from the forge.all browser bundle. Only unauthenticated remote interaction is required in the CVSS vector (AV:N/PR:N/UI:N) but the vector also carries AC:H, reflecting that the attacker must control or influence the server the client connects to and the application must actually load forge.http; crucially forge.http is not loaded by require('node-forge'), so ordinary Node.js TLS/crypto consumers are unaffected. Its impact is confined to the JavaScript realm's object model (C:N/I:L/A:L, CVSS 3.1 base 4.8), and no public exploit code or active exploitation is identified in the available data; node-forge 1.4.1 fixes the issue.
CBC and ECB decryption in node-forge 1.4.0 and earlier accepts malformed PKCS#7 padding, so an application that treats a successful decipher.finish() as proof of valid data can accept tampered ciphertext with up to four blocks of trailing plaintext silently removed. Affected are npm users of the digitalbazaar/forge package who decrypt attacker-influenced data in CBC or ECB mode, including PKCS#7 EncryptedData/EnvelopedData, PKCS#12 and encrypted private keys; impact is integrity-only (CVSS 3.1 3.7, AC:H, no confidentiality or availability effect) because CBC/ECB without a MAC are already malleable. The flaw is fixed in 1.4.1, and the vendor advisory publishes a short proof-of-concept decrypt snippet showing a Wycheproof invalid vector returning true on 1.4.0 and false on 1.4.1; it demonstrates the padding acceptance but gives no remote attack path, so no active exploitation is indicated by the available data.
OID-based authorization bypass in node-forge through 1.4.0: asn1.oidToDer() fails to range-check the first two arcs of an OID string, so input such as 0.42.840.113549.1.1.1 is encoded as the DER of rsaEncryption (1.2.840.113549.1.1.1). This affects only applications that accept an OID string from untrusted input, check or authorize that string, and then re-encode it with node-forge when building certificates, CSRs or other ASN.1 structures; DER parsing is unaffected and there is no confidentiality or availability impact. node-forge 1.4.1 fixes the truncation, a public PoC reference exists in the GHSA (not verified as working exploit code), and this is a genuinely low-priority issue despite being worth patching (vuln.today: monitor).
Certificate chain verification in node-forge 1.4.0 and earlier chooses the RSA padding scheme and RSASSA-PSS parameters from the issuer certificate rather than from the child certificate being verified, so a certificate whose signatureAlgorithm fields are labeled RSASSA-PSS is accepted on a PKCS#1 v1.5 signature when the trusted issuer was itself PKCS#1 v1.5-signed. The practical impact is confined to applications that treat a certificate's declared signature scheme as a trust decision - the signature must still be produced with the trusted issuer's private key, so certificate identity cannot be forged, and there is no confidentiality or availability impact. Rated 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N), unauthenticated from the network, with no KEV listing or confirmed working exploit code reported; the vendor advisory does include a public proof-of-concept reproduction procedure, and node-forge 1.4.1 fixes the flaw, so this is a monitor-priority item rather than an emergency.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severity (CVSS 8.7), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Integer Overflow vulnerability could allow attackers to cause unexpected behavior through arithmetic overflow.
An interpretation-conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and earlier enables unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a. Rated high severity (CVSS 8.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
The package node-forge before 0.10.0 is vulnerable to Prototype Pollution via the util.setPath function. Rated high severity (CVSS 7.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.