CVE-2026-4601: Jsrsasign Information Disclosure Flaw

CVE-2026-4601 Overview

CVE-2026-4601 is a critical cryptographic vulnerability affecting the jsrsasign JavaScript cryptography library. Versions before 11.1.1 are vulnerable to a Missing Cryptographic Step in the DSA (Digital Signature Algorithm) signing implementation. Specifically, the KJUR.crypto.DSA.signWithMessageHash function fails to properly validate the signature components, allowing an attacker to recover private keys by forcing the signature values r or s to be zero.

This flaw occurs because the library emits an invalid signature without retrying when zero values are generated, violating the DSA specification which requires both r and s to be non-zero. An attacker exploiting this vulnerability can solve for the private key x from the resulting malformed signature, leading to complete compromise of cryptographic operations.

Critical Impact
Private key recovery through forced zero-value signature generation enables attackers to impersonate legitimate signers, forge digital signatures, and compromise all cryptographic operations relying on the affected DSA implementation.

Affected Products

jsrsasign versions prior to 11.1.1
Node.js applications using vulnerable jsrsasign packages
Web applications implementing DSA signing with jsrsasign

Discovery Timeline

2026-03-23 - CVE-2026-4601 published to NVD
2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-4601

Vulnerability Analysis

The vulnerability resides in the DSA signature generation process within the KJUR.crypto.DSA.signWithMessageHash function. According to the DSA specification (FIPS 186-4), both signature components r and s must be non-zero integers. If either value computes to zero during signature generation, the implementation must regenerate the ephemeral key k and retry the signature computation.

The vulnerable jsrsasign implementation fails to perform this critical validation step. When the signature generation produces a zero value for either r or s, the library returns the invalid signature rather than regenerating with a new ephemeral key. This missing cryptographic step creates a mathematical relationship that allows an attacker to derive the private key.

The attack scenario involves an attacker who can influence or observe signature operations. By manipulating inputs to force zero-value outputs, or by collecting signatures where zero values naturally occur (though statistically rare), the attacker can exploit the algebraic properties of DSA to extract the private key x. Once the private key is recovered, all signatures generated with that key can be forged.

Root Cause

The root cause is the absence of a validation check in the DSA signing implementation that should verify r ≠ 0 and s ≠ 0 before returning the signature. The DSA algorithm requires regeneration of the ephemeral key k when either component equals zero, but this retry logic was missing from the implementation. This is classified as CWE-325 (Missing Required Cryptographic Step).

Attack Vector

The attack vector is network-based, requiring no user interaction or privileges. An attacker can exploit this vulnerability by:

Triggering DSA signature operations through normal application interfaces
Manipulating message hash inputs or observing signature outputs
Identifying signatures where r or s equals zero
Using the mathematical relationship in DSA to solve for the private key x

The attack exploits the following mathematical property: when s = 0, the DSA equation s = k⁻¹(H(m) + xr) mod q reveals information about the private key x since the inverse of k and the hash value H(m) are known or can be derived.

The vulnerability mechanism can be understood by examining the DSA signing process. In a correct implementation, after computing r = (g^k mod p) mod q and s = k⁻¹(H(m) + xr) mod q, the implementation must verify that neither r nor s equals zero. If either is zero, a new random k must be selected and the computation repeated. The vulnerable jsrsasign implementation skips this validation, allowing invalid signatures to be emitted. Technical details and a proof-of-concept can be found in the security researcher's Gist.

Detection Methods for CVE-2026-4601

Indicators of Compromise

Presence of jsrsasign package versions below 11.1.1 in package.json or package-lock.json
DSA signatures containing zero values in the r or s components
Unusual patterns in cryptographic operations or signature validation failures
Evidence of signature analysis or brute-force attempts against DSA-signed content

Detection Strategies

Implement software composition analysis (SCA) to identify vulnerable jsrsasign versions in your dependency tree
Monitor for DSA signature anomalies where r or s components equal zero in application logs
Use static code analysis tools to detect usage of KJUR.crypto.DSA.signWithMessageHash in applications with vulnerable library versions
Deploy runtime application self-protection (RASP) to detect cryptographic operation anomalies

Monitoring Recommendations

Enable verbose logging for cryptographic operations to capture signature generation events
Implement alerting for signature validation failures that may indicate exploitation attempts
Monitor npm audit reports and security advisories for jsrsasign package updates
Track dependency updates across development and production environments using automated vulnerability scanning

How to Mitigate CVE-2026-4601

Immediate Actions Required

Upgrade jsrsasign to version 11.1.1 or later immediately across all affected projects
Audit all applications using jsrsasign for DSA signing functionality
Review and regenerate any DSA key pairs that may have been compromised through this vulnerability
Implement additional signature validation to detect zero-value components before processing

Patch Information

The vulnerability has been addressed in jsrsasign version 11.1.1. The fix implements proper validation of signature components r and s, ensuring retry logic when zero values are generated. Review the GitHub commit for implementation details. Additional context is available in the pull request discussion and the Snyk vulnerability report.

Workarounds

If immediate upgrade is not possible, implement wrapper functions that validate signature outputs before use
Consider temporarily disabling DSA signing functionality and using alternative algorithms (RSA, ECDSA) until patching is complete
Add application-level checks to reject signatures where r or s equals zero
Implement rate limiting on signature operations to reduce exploitation opportunities

bash

# Upgrade jsrsasign to patched version
npm update jsrsasign@11.1.1

# Verify installed version
npm list jsrsasign

# Audit for vulnerabilities
npm audit