CVE-2026-33894

What it actually does

The flaw is an improper RSA PKCS#1 v1.5 signature verification weakness in digitalbazaar Forge / node-forge before version 1.4.0. When verifying RSASSA-PKCS1-v1_5 signatures that use low public exponent RSA keys, especially e=3, Forge may accept mathematically forged signatures because it does not strictly validate the ASN.1 DigestInfo structure and does not enforce the required minimum PKCS#1 v1.5 padding length. An attacker who can supply a signature and influence or select a low-exponent public key may craft a signature blob that passes verification without possession of the corresponding private key, undermining authentication, integrity checks, certificate-like trust decisions, signed token validation, or signed object verification implemented with vulnerable Forge APIs.

Why it matters to the business

Applications that rely on vulnerable versions of node-forge for RSA signature verification may incorrectly trust attacker-controlled data as authentic. This can affect login or authorization flows, signed configuration or update mechanisms, document or message integrity checks, custom PKI validation, or any workflow where a valid digital signature is treated as proof of trust. The CVSS score is high because exploitation can compromise integrity remotely without authentication or user interaction, although the currently reported EPSS is low and the issue is not listed in CISA KEV, indicating no broad confirmed exploitation at this time. Because node-forge is commonly embedded as a transitive dependency in JavaScript applications, exposure may exist even where teams do not call the library directly.

How an attack unfolds

An attacker first identifies an application path that verifies RSA PKCS#1 v1.5 signatures using a vulnerable node-forge version. The attacker then determines whether the verification path accepts or uses a low-exponent RSA public key, most notably e=3, or whether the attacker can provide a key, certificate, signed object, token, or message that is verified by Forge. Using a Bleichenbacher-style construction, the attacker creates a malformed signature where carefully chosen bytes and extra garbage inside the ASN.1 structure cause Forge's permissive parser to interpret the signature as valid. Because Forge also fails to enforce the required minimum padding length, the attacker has additional room to craft a value that satisfies the vulnerable verification logic. If accepted, the forged signature can cause the application to treat attacker-controlled content as trusted, potentially allowing unauthorized actions, bypass of integrity controls, or acceptance of malicious signed material.

How to fix it

Upgrade digitalbazaar Forge / node-forge to version 1.4.0 or later wherever it is used directly or transitively. Regenerate lockfiles and redeploy applications so the patched package is actually present at runtime, not only in source manifests. If immediate upgrade is not possible, reduce exposure by rejecting RSA public keys with exponent e=3 in verification paths, avoiding RSASSA-PKCS1-v1_5 where possible, preferring modern schemes such as RSA-PSS with strict verification, and using platform-vetted cryptographic libraries where feasible. Review any custom certificate, token, package, document, firmware, configuration, or message-signing validation logic that depends on Forge's RSA verification APIs. Because fixed_versions was not supplied separately in the input but the advisory description states the fix is version 1.4.0, treat 1.4.0 as the minimum patched version.

How to confirm the fix worked

Confirm that all package manifests and lockfiles resolve node-forge / forge to version 1.4.0 or later. Use dependency inventory tooling such as npm ls node-forge, yarn why node-forge, pnpm why node-forge, software composition analysis, or SBOM scanning to detect both direct and transitive copies. Inspect built containers, serverless bundles, browser bundles, and packaged applications because JavaScript dependencies may be vendored or bundled at build time. Validate that runtime artifacts no longer include vulnerable node-forge code. Where practical, add a regression test using known malformed RSA PKCS#1 v1.5 signatures for e=3 keys to ensure verification fails. Also confirm that signature verification code rejects weak or unexpected key parameters and that security-sensitive workflows do not accept attacker-supplied trust anchors unless explicitly intended.

Typical attack path

1. Find an application, service, API, or client-side workflow that uses digitalbazaar Forge / node-forge before version 1.4.0 for RSA PKCS#1 v1.5 signature verification.
2. Identify a verification context involving a low-exponent RSA public key, especially exponent e=3, or a workflow where the attacker can submit the public key, certificate, signed artifact, or signed message.
3. Craft a Bleichenbacher-style forged signature with malformed ASN.1 DigestInfo content and insufficient or manipulated PKCS#1 v1.5 padding.
4. Submit the forged signature together with attacker-controlled data, token, certificate, message, configuration, document, or update package.
5. Rely on vulnerable Forge verification behavior to accept the forged signature as valid.
6. Abuse the resulting trust decision to bypass integrity checks, impersonate a signed issuer, authorize unauthorized data, or deliver malicious trusted content.

How to detect it

Detecting prior exploitation is difficult because successful signature forgery may look like a normal successful verification unless the application logs signature metadata, key parameters, or rejected parsing details. Review application, API gateway, authentication, authorization, package-update, document-processing, message-verification, and certificate-validation logs for unusual successful signature validations involving RSA keys with public exponent e=3, unexpected issuers or public keys, sudden changes in signed payload content, repeated failed signature attempts followed by success, or signed objects with malformed ASN.1 structures. If raw signed artifacts are retained, perform offline forensic parsing with a strict ASN.1 and PKCS#1 v1.5 verifier to identify signatures that vulnerable Forge accepted but a strict implementation rejects. Investigate any acceptance of signed data where the key, certificate, token header, document signer, or trust anchor was supplied by an untrusted party. Threat hunting should focus on integrity outcomes: unauthorized configuration changes, accepted malicious packages or documents, anomalous token claims, unexpected certificate chains, or signed messages from unfamiliar keys. There are no universal network indicators for this vulnerability because exploitation is data-format and application-context dependent.

What your security team should do

• Prioritize inventory of all applications, services, build artifacts, and client packages that include digitalbazaar Forge / node-forge, including transitive dependencies.
• Upgrade all affected instances to node-forge 1.4.0 or later and rebuild/redeploy affected artifacts.
• Search code for RSA PKCS#1 v1.5 signature verification paths using Forge and identify whether they validate tokens, certificates, signed configuration, signed packages, documents, messages, or update metadata.
• Add compensating controls to reject RSA keys with public exponent e=3 in security-sensitive verification workflows until patched versions are fully deployed.
• Prefer RSA-PSS or other modern signature verification schemes for new designs and avoid accepting attacker-controlled keys or trust anchors without strict policy validation.
• Review authentication, authorization, signed-content, and update-delivery logs for anomalous successful validations involving unexpected issuers, keys, or malformed signed objects.
• Add dependency scanning gates to prevent reintroduction of node-forge versions earlier than 1.4.0.
• Because the issue is not currently in CISA KEV and EPSS is low, handle as high-priority integrity risk rather than confirmed mass exploitation, with urgency increased for internet-facing verification endpoints or signed-update mechanisms.