CVE-2026-4601
Private Key Recovery via Missing Cryptographic Step in jsrsasign DSA
Publication date: 2026-03-23
Last updated on: 2026-04-29
Assigner: Snyk
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| jsrsasign_project | jsrsasign | to 11.1.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-325 | The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by analyzing signatures generated by the jsrsasign library, specifically checking if the DSA signature components r or s are zero. Signatures with r=0 or s=0 are invalid and indicate the vulnerable behavior.
Since the vulnerability arises in the function KJUR.crypto.DSA.signWithMessageHash, you can detect it by capturing and inspecting DSA signatures produced by this library in your environment.
There are no direct network scanning commands provided in the resources, but you can use cryptographic inspection tools or scripts to parse signatures and verify if any have r=0 or s=0.
For example, you could write a script to extract DSA signatures from your system or network traffic and check the signature components. If you find any signatures where r or s equals zero, it indicates the presence of the vulnerable jsrsasign versions.
Can you explain this vulnerability to me?
CVE-2026-4601 is a vulnerability in the jsrsasign JavaScript cryptographic library affecting versions before 11.1.1. It concerns the DSA (Digital Signature Algorithm) signing implementation, specifically the function signWithMessageHash. The issue arises because the library can produce signatures where either of the signature components, r or s, is zero. According to cryptographic standards (FIPS 186-4), if r or s equals zero, the signing process must retry with a new ephemeral key k. However, jsrsasign did not perform this retry and emitted invalid signatures with zero values.
This flaw allows an attacker to recover the private key by exploiting signatures where s = 0. The attacker can solve for the private key x using the formula x = -H(m) * r^-1 mod q, where H(m) is the message hash and q is a DSA parameter. Although the probability of s being zero naturally is very low, the lack of retry enables forced exploitation.
The vulnerability is classified as a missing cryptographic step (CWE-325) and violates the FIPS 186-4 standard. The fix involves adding a retry loop in the signing function to regenerate the ephemeral key k and recompute r and s until both are non-zero, ensuring valid signatures.
How can this vulnerability impact me? :
This vulnerability can have a critical impact on the security of applications using the vulnerable jsrsasign library for DSA signatures. An attacker can remotely exploit the flaw without any privileges or user interaction to recover the private key used for signing.
With the private key compromised, the attacker can forge valid digital signatures, undermining the confidentiality and integrity of signed data or communications. This can lead to unauthorized actions, data tampering, or impersonation of trusted entities.
The vulnerability has a high severity rating (CVSS around 8.7 to 9.4), reflecting its significant impact on confidentiality and integrity, though it does not affect availability.
To mitigate this risk, users must upgrade jsrsasign to version 11.1.1 or later, where the signing process correctly retries to avoid zero-valued signature components.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
What immediate steps should I take to mitigate this vulnerability?
The immediate and recommended mitigation step is to upgrade the jsrsasign library to version 11.1.1 or later, where the vulnerability has been fixed.
The fix involves adding a retry loop in the signature generation process that ensures the signature components r and s are never zero, complying with the FIPS 186-4 standard.
If upgrading is not immediately possible, consider auditing and blocking signatures with zero components, as these indicate invalid and vulnerable signatures.