CVE-2026-4602: Versions of the package jsrsasign before 11.1.1 are vulnerable to Incorrect Conversion between Numeric Type...
Versions of the package jsrsasign before 11.1.1 are vulnerable to Incorrect Conversion between Numeric Types due to handling negative exponents in ext/jsbn2.js. An attacker can force the computation of incorrect modular inverses and break signature verification by calling modPow with a negative exponent.
Security readout for executives and security teams
Plain-English summary
CVE-2026-4602 affects jsrsasign versions before 11.1.1. A math-conversion flaw can make cryptographic calculations return wrong results, potentially undermining signature verification. Treat this as high priority where jsrsasign protects authentication, tokens, documents, or signed data.
Executive priority
Prioritize remediation this cycle for systems relying on jsrsasign for trust decisions. The flaw targets cryptographic verification, has public proof-of-concept signals, and affects a common JavaScript package, but current sources do not prove active exploitation.
Technical view
The issue is CWE-681 in ext/jsbn2.js: handling of negative exponents in modPow can force incorrect modular inverse computation. Sources describe impact as breaking signature verification. The CVSS 4.0 score is 8.7 high, with network, unauthenticated, low-complexity attack characteristics and proof-of-concept maturity indicated.
Likely exposure
Exposure is most likely in applications or bundled products using jsrsasign before 11.1.1, including org.webjars.npm:jsrsasign. Risk is highest where untrusted data reaches jsrsasign cryptographic verification paths.
Exploitation context
The bundle does not show CISA KEV listing or active exploitation. It does include a public gist reference and CVSS exploit maturity marked proof-of-concept, so defenders should assume public technical detail exists without treating this as known in-the-wild exploitation.
Researcher notes
Key research focus is reachability: identify whether vulnerable modPow behavior is reachable through signature verification in the application’s use of jsrsasign. Avoid assuming every install is exploitable, but treat exposed verification workflows as higher risk.
Mitigation direction
Upgrade jsrsasign to 11.1.1 or later where the package is directly used.
Update org.webjars.npm:jsrsasign dependencies to a non-vulnerable release when available.
Apply relevant Red Hat RHSA updates for affected Red Hat-maintained packages.
Check vendor guidance for products that bundle jsrsasign indirectly.
Prioritize systems where jsrsasign validates authentication tokens or signed business data.
Validation and detection
Inventory npm, lockfile, Maven, and WebJars dependencies for jsrsasign versions before 11.1.1.
Confirm dependency scanners no longer report SNYK-JS-JSRSASIGN-15371175 or SNYK-JAVA-ORGWEBJARSNPM-15812274.
Review whether untrusted inputs can reach jsrsasign signature verification or modPow-related code paths.
Verify deployed artifacts contain the upgraded dependency, not only source manifests.
Track Red Hat errata status for any downstream packages in use.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-681: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-681 · source CWE mapping
Incorrect Conversion between Numeric Types
Incorrect Conversion between Numeric Types represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.