node-forge EUVD-2026-113331

Exploitation requires an application running node-forge <=1.4.0 that makes a security decision based on a certificate's DECLARED signature algorithm (for example, a policy that accepts only RSASSA-PSS-signed certificates). The attacker supplies a certificate whose signatureAlgorithm fields are labeled RSASSA-PSS but whose signature is actually PKCS#1 v1.5, which node-forge accepts when the trusted issuer itself was signed with PKCS#1 v1.5 - because verification used the issuer's scheme instead of the child's. The no-private-key variant simply relabels the outer (unsigned) signatureAlgorithm of an existing CA-signed certificate. Strong limiting factors keep real-world risk low: the signature must still have been produced by the trusted issuer's private key, so certificate identity cannot be forged; the impact is confined to applications that treat the declared signature scheme as a trust signal; there is no confidentiality or availability impact; and it is fixed in 1.4.1.

This is a genuinely low-priority issue that the signals agree on. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N = 3.7 Low) shows only a Low integrity impact and no confidentiality or availability impact, with high attack complexity. The vuln.today decision label is 'monitor,' the lowest urgency tier, and the issue is NOT in CISA KEV (no confirmed active exploitation). No EPSS score was supplied in the input, so exploitation probability cannot be quantified - treat that as a data gap rather than evidence of low likelihood. SSVC component fields (automatable, technical impact) were not provided beyond the 'monitor' label. A detailed proof-of-concept is published in the GHSA advisory, but PoC availability is a distinct signal from active exploitation and does not raise this to an emergency. Crucially, the flaw does NOT enable certificate identity forgery: the signature must still be produced with the trusted issuer's private key. It only lets a certificate be relabeled with a different RSA signature scheme (RSASSA-PSS vs PKCS#1 v1.5), defeating applications whose security policy keys off the declared signature algorithm. The CVSS 4.0 score in the advisory (6.3 Moderate) is higher purely because 4.0 weights integrity more; the vendor explicitly says the rating follows CVSS 3.1 Low. Net: a real correctness/cryptographic-policy bug worth patching in routine maintenance, not an incident-grade priority.

An application uses node-forge's verifyCertificateChain()/certificate.verify() to enforce a policy that only RSASSA-PSS-signed certificates are accepted. An attacker takes a certificate legitimately signed by the trusted CA with PKCS#1 v1.5 and relabels only its outer (unsigned) signatureAlgorithm field as RSASSA-PSS; on node-forge <=1.4.0 it still verifies and reports signatureOid as RSASSA-PSS, bypassing the policy. A detailed PoC (including a no-private-key relabel variant) is published in the GHSA advisory; attack complexity is high (AC:H) and no identity forgery is possible since the signature must still come from the trusted issuer's key.