EUVD-2026-14375
GHSA-wvqx-v3f6-w8rh
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify target using jsrsasign <11.1.1
-
DeliveryCraft malicious DSA certificate with g=1, y=1, r=1
-
ExploitSubmit certificate/JWT to verification endpoint
-
ExecutionTrigger X509.verifySignature() with malicious parameters
-
PersistBypass signature validation
-
ImpactGain unauthorized access with forged credentials
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Exploitation requires the vulnerable application to (1) use jsrsasign library version below 11.1.1 for DSA signature or X.509 certificate verification, (2) accept and process DSA-algorithm certificates or signatures from attacker-controlled or untrusted sources rather than using pre-configured trusted certificates with validated parameters, and (3) allow the attacker to supply domain parameters (p, q, g) and public key (y) values - typically through accepting arbitrary X.509 certificates, JWKS endpoints, or JWTs with embedded public keys. The high attack complexity (AC:H in CVSS vector) reflects that many modern applications default to RSA or ECDSA rather than DSA, and well-architected systems validate certificates against trusted CA roots rather than accepting arbitrary parameters. Exploitation is limited by the decreasing prevalence of DSA in contemporary cryptographic deployments (TLS 1.3 and modern JWT implementations favor ECDSA/EdDSA), and by applications that implement certificate pinning or strict issuer validation. No user interaction (UI:N) or authentication (PR:N) required once the application processes attacker-supplied cryptographic material. |
| Impact | Real-world risk is moderate and highly context-dependent despite the high CVSS 8.1 score. The CVSS vector (AV:N/AC:H) indicates network-exploitable but high complexity - exploitation requires the application to accept attacker-supplied DSA parameters rather than using trusted, pre-validated domain parameters from certificate authorities or configuration. EPSS score of 0.01% (2nd percentile) suggests minimal automated exploitation attempts, consistent with SSVC assessment that exploitation is not automatable and requires proof-of-concept knowledge. However, technical impact is total per SSVC, meaning successful exploitation completely bypasses authentication/integrity. The attack is practical when applications dynamically parse X.509 certificates or DSA public keys from untrusted sources without parameter validation - common in JWT libraries accepting arbitrary 'alg' headers or certificate chains. Proof-of-concept code exists (GitHub gist from Kr0emer), lowering exploitation barrier for targeted attacks. Priority depends critically on whether your applications (1) use jsrsasign for signature verification, (2) process DSA-signed content (less common than RSA/ECDSA in modern PKI), and (3) accept certificates/keys from untrusted sources. Not in CISA KEV, indicating no confirmed widespread active exploitation. |
| Exploit ScenarioDerived | An attacker hosting a malicious API gateway sends a client application a crafted JWT token claiming admin privileges, signed with DSA algorithm using domain parameters g=1, y=1, and signature component r=1. The victim application running jsrsasign <11.1.1 calls X509.verifySignature() or KJUR.crypto.DSA verification, which incorrectly validates the token despite the attacker never possessing the legitimate private key. The application grants the attacker administrative access, allowing data exfiltration or privilege escalation. Proof-of-concept exploit code demonstrating parameter manipulation is publicly available at https://gist.github.com/Kr0emer/bf15ddc097176e951659a24a8e9002a7. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Apr 29, 2026
Cryptographic signature bypass in jsrsasign before 11.1.1 allows remote attackers to forge DSA signatures and X.509 certificates by supplying malicious domain parameters (g=1, y=1, r=1) that cause verification functions to incorrectly validate any message hash. This actively undermines authentication and integrity checks in applications using the library for JWT validation, certificate verification, or digital signatures. EPSS score is negligible (0.01%) despite proof-of-concept availability, and CISA SSVC classifies this as requiring proof-of-concept but not automatable, indicating targeted exploitation risk rather than widespread scanning.
Earlier versions of this analysis (1)
A cryptographic signature verification vulnerability exists in the jsrsasign JavaScript library before version 11.1.1 that allows attackers to forge DSA signatures and X.509 certificates. The vulnerability affects DSA domain-parameter validation in KJUR.crypto.DSA.setPublic, enabling complete bypass of signature verification by supplying malicious domain parameters (g=1, y=1, r=1). A proof-of-concept exploit is publicly available (CVSS:3.1 E:P rating) demonstrating active exploitation feasibility, though the attack complexity is rated high and no KEV listing indicates limited widespread exploitation to date.
RemediationAI
Upgrade jsrsasign to version 11.1.1 or later, which implements proper DSA domain-parameter validation per the fix in GitHub commit 37b4c06b145c7bfd6bc2a6df5d0a12c56b15ef60 and pull request #646 (https://github.com/kjur/jsrsasign/pull/646). Red Hat users should apply patches per their respective RHSA advisories. If immediate upgrade is not feasible, implement these compensating controls with noted trade-offs: (1) Disable DSA algorithm support in signature verification code and reject any certificates or tokens using DSA signatures - this breaks legitimate DSA-signed content but RSA and ECDSA remain functional; (2) Implement strict allowlisting of trusted certificate authorities and reject any certificates with unexpected issuers - reduces attack surface but requires maintaining CA lists and breaks dynamic trust scenarios; (3) Add pre-verification checks to reject DSA public keys where g=1 or y=1 before calling jsrsasign verification functions - requires modifying application code and understanding DSA parameter constraints. Do not rely solely on updating cryptographic libraries in transitive dependencies; verify that your application code and direct dependencies have also upgraded. Test thoroughly as cryptographic library updates can expose previously-masked implementation bugs in consuming applications.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
jsrsasign is a pure JavaScript cryptographic library implementing RSA, ECDSA, DSA signature schemes and X.509 certificate handling, commonly used in Node.js and browser environments for JWT token validation and PKI operations. The vulnerability (CWE-347: Improper Verification of Cryptographic Signature) exists in the DSA domain-parameter validation logic within KJUR.crypto.DSA.setPublic and related verification flows in src/dsa-2.0.js. DSA signature verification requires validating that domain parameters (p, q, g) and public key (y) satisfy mathematical properties - specifically that g generates a subgroup of order q. By accepting attacker-controlled parameters where g=1 and y=1, the verification equation (v = r) becomes trivially true when the attacker sets r=1, regardless of the message hash or actual signature value s. This bypasses the fundamental cryptographic assurance that only the holder of the private key can produce valid signatures.
Know when Jsrsasign gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Primary rating from Vendor (snyk).
CVSS VectorVendor: snyk
Lifecycle Timeline
4DescriptionCVE.org
Versions of the package jsrsasign before 11.1.1 are vulnerable to Improper Verification of Cryptographic Signature via the DSA domain-parameter validation in KJUR.crypto.DSA.setPublic (and the related DSA/X509 verification flow in src/dsa-2.0.js). An attacker can forge DSA signatures or X.509 certificates that X509.verifySignature() accepts by supplying malicious domain parameters such as g=1, y=1, and a fixed r=1, which make the verification equation true for any hash.
Blast Radius
ecosystem impact- 38 npm packages depend on jsrsasign (10 direct, 28 indirect)
Ecosystem-wide dependent count for version 11.1.1.
Executive ViewAI
jsrsasign versions before 11.1.1 contain a cryptographic signature bypass vulnerability that allows attackers to forge DSA signatures and X.509 certificates, directly compromising authentication and integrity validation in applications relying on this library for JWT, certificate, or digital signature verification. Organizations using jsrsasign must upgrade immediately, as successful exploitation enables attackers to impersonate users, bypass certificate validation, and tamper with signed messages without detection.
Vendor-released patch: jsrsasign 11.1.1 or later. Apply vendor patch immediately. If immediate patching is impossible, implement external signature validation using independent cryptographic libraries and disable DSA signature schemes in favor of RSA or ECDSA pending patch deployment.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Related Vulnerabilities in jsrsasign Cryptographic Implementation Flaws
View all 6An issue was discovered in the jsrsasign package before 8.0.17 for Node.js. Rated critical severity (CVSS 9.8), this vul
An issue was discovered in the jsrsasign package before 8.0.18 for Node.js. Rated critical severity (CVSS 9.8), this vul
The package jsrsasign before 10.5.25 are vulnerable to Improper Verification of Cryptographic Signature when JWS or JWT
An issue was discovered in the jsrsasign package through 8.0.18 for Node.js. Rated high severity (CVSS 7.5), this vulner
Versions of the package jsrsasign before 11.0.0 are vulnerable to Observable Discrepancy via the RSA PKCS1.5 or RSAOAEP
In the jsrsasign package through 10.1.13 for Node.js, some invalid RSA PKCS#1 v1.5 signatures are mistakenly recognized
Exploit-DB