jsrsasign DSA verification bypass enables X.509 certificate forgery

TL;DR — A DSA domain-parameter validation flaw in jsrsasign can let attackers forge signatures and X.509 certificates that pass X509.verifySignature() validation.

What happened

jsrsasign is a JavaScript cryptography library commonly used for signing and verifying JWS/JWT-like artifacts and for working with X.509 and related PKI primitives.

NVD published CVE-2026-4600, describing improper verification of cryptographic signatures caused by insufficient DSA domain-parameter validation in KJUR.crypto.DSA.setPublic (and the related DSA/X.509 verification flow in src/dsa-2.0.js). Per the NVD description, an attacker can supply malicious DSA domain parameters (example values called out include g=1, y=1, and a fixed r=1) that make the DSA verification equation evaluate as valid for any hash, enabling forged DSA signatures and forged X.509 certificates that X509.verifySignature() accepts.

NVD has not yet provided an enrichment score; the CNA source shown on NVD (Snyk) lists CVSS v4.0 9.1 (Critical) and CVSS v3.1 7.4 (High). This is a high-impact class of bug for platform teams because signature verification failures collapse trust boundaries in identity, token validation, and certificate-based authentication flows — and crypto “parameter validation” mistakes are a recurring root cause in real-world verification bypasses.

Who is impacted

• Applications and services that use jsrsasign for DSA signature verification.
• Systems that rely on jsrsasign’s X.509 verification flow (notably X509.verifySignature()) on attacker-influenced certificates or signed artifacts.
• Any environment where jsrsasign is used in security-sensitive trust decisions (authn/z, request signing, or certificate validation) and untrusted inputs can reach verification code paths.

What to do now

• Follow upstream remediation guidance and apply a release that is not in the affected range (NVD states: versions of jsrsasign before 11.1.1 are vulnerable).
• Inventory where jsrsasign is pulled in (directly or transitively) across Node.js services, front-end bundles, and internal tooling that performs signature or certificate verification.
• Identify and prioritize any verification paths that process untrusted signatures/certificates (external integrations, SSO/SAML gateways that touch cert material, request-signing endpoints, and any PKI validation logic).
• If compromise is suspected, treat it as a trust-boundary incident: review where DSA/X.509 verification results gate access, and rotate credentials/keys whose integrity depends on impacted verification.