CVE-2026-118774 in Forge
Summary
by MITRE • 10/29/2026
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used certificate.verify(child), _verifySignature(), lib/x509.js to process the relevant input or security decision. node-forge selected RSA padding and RSASSA-PSS parameters from the issuer certificate rather than the child certificate being verified. A child labeled as RSASSA-PSS could therefore be accepted with a PKCS#1 v1.5 signature when the issuer used PKCS#1 v1.5. The signature still had to be produced with the trusted issuer's private key, so this did not permit certificate identity forgery, but it could bypass policies that require a declared signature scheme. This issue is fixed in version 1.4.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The Forge library, also known as node-forge, serves as a native implementation of Transport Layer Security protocols within the JavaScript ecosystem. It provides developers with tools to handle cryptographic operations such as encryption, decryption, and certificate validation directly in client-side or server-side Node.js environments. The integrity of these security mechanisms relies heavily on strict adherence to standard-defined parameters during the verification process. Specifically, when validating X.509 certificates, the library must ensure that every aspect of the signature matches the expectations set by both the issuing authority and the certificate itself. A critical flaw was identified in versions prior to 1.4.1 where this validation logic contained a significant deviation from expected cryptographic behavior regarding RSA padding schemes.
The technical root cause of this vulnerability lies in how the library processes the RSASSA-PSS signature parameters during certificate verification. When node-forge validates a child certificate signed by an issuer, it is responsible for ensuring that the signature algorithm and its associated parameters are consistent with what was declared in both the parent and child certificates. In the affected versions, the implementation incorrectly selected RSA padding and RSASSA-PSS parameters from the issuer certificate rather than extracting them from the child certificate being verified. This logic error meant that if a child certificate explicitly stated it used an RSASSA-PSS signature scheme, but the issuing authority's certificate utilized PKCS#1 v1.5 for its own signatures or general configuration, node-forge would accept the validation based on the issuer's parameters rather than enforcing the strict requirements of the child certificate.
This discrepancy creates a scenario where a certificate labeled as RSASSA-PSS could be accepted even if it was signed using PKCS#1 v1.5 padding, provided that the issuing authority used PKCS#1 v1.5 in its own context. While this does not allow an attacker to forge a new identity or create a valid signature without possessing the trusted issuer's private key, it represents a significant deviation from strict cryptographic compliance. The vulnerability essentially allows for a bypass of policies that mandate specific signature schemes. For applications and systems that rely on node-forge to enforce security policies requiring explicit adherence to RSASSA-PSS standards, this flaw means those controls can be circumvented by presenting certificates with mismatched but technically valid signatures under the flawed validation logic.
From an industry standard perspective, this issue aligns with CWE-295 Improper Certificate Validation and CWE-347 Improper Verification of Cryptographic Signature. The failure to correctly verify that the signature algorithm matches the declared type in the certificate is a classic example of improper verification mechanisms. In terms of MITRE ATT&CK mapping, while not directly exploitable for identity forgery due to the requirement of the private key, this behavior could be leveraged in sophisticated attacks where an adversary might attempt to bypass application-level checks that rely on strict signature scheme enforcement. Such bypasses can weaken the overall security posture by allowing certificates with weaker or unexpected cryptographic properties to pass validation processes intended to enforce higher standards.
The operational impact is primarily related to policy compliance and defense-in-depth strategies rather than immediate data compromise or identity theft. Organizations using node-forge for TLS termination, certificate pinning, or strict PKI enforcement may find that their security controls are less effective than anticipated. If an application assumes that a validated RSASSA-PSS certificate guarantees the use of PSS padding throughout its lifecycle, this vulnerability undermines that assumption. This can lead to inconsistencies in audit logs and potential vulnerabilities if downstream systems rely on the specific properties of PSS signatures for further cryptographic operations or trust decisions.
To mitigate this risk, organizations must upgrade node-forge to version 1.4.1 or later immediately. The fix ensures that signature parameters are correctly extracted from the child certificate being verified rather than inheriting them incorrectly from the issuer. In addition to updating dependencies, security teams should review their application logic for any assumptions about signature schemes and implement additional validation layers where necessary. Regularly auditing third-party cryptographic libraries against current CVE databases is essential to maintain a robust security posture in JavaScript-based environments.