CVE-2026-4602: 
JavaScript vulnerability analysis and mitigation

CVE-2026-4602 is an Incorrect Conversion between Numeric Types vulnerability in the jsrsasign npm package (a pure JavaScript cryptographic library) affecting all versions before 11.1.1. The flaw resides in ext/jsbn2.js and allows an unauthenticated network attacker to force computation of incorrect modular inverses by calling BigInteger.modPow() with a negative exponent, effectively breaking signature verification. The vulnerability was disclosed on February 21, 2026, and published to NVD on March 23, 2026. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 7.7 (High) (Snyk, Red Hat Bugzilla).

The root cause is classified as CWE-681 (Incorrect Conversion between Numeric Types). The bnModPow function in Tom Wu's jsbn.js (bundled as ext/jsbn2.js) performs exponent bit-scanning on the raw two's-complement representation without first checking the sign of the exponent. This produces two silent failure modes: Mode A — when exp = -1, bitLength() returns 0, triggering an early-return of BigInteger.ONE regardless of base or modulus; Mode B — when exp = -k (k > 1), the function scans the two's-complement bit pattern as if it were a large positive number, yielding a numerically plausible but mathematically wrong result. In both cases, no exception or warning is raised. The fix, merged via PR #650, adds a sign check at the entry of bnModPow: if e.signum() < 0, it computes this.modInverse(m).modPow(e.negate(), m) instead (GitHub Gist, GitHub PR, GitHub Commit).

The primary impact is a Denial of Service against cryptographic signature workflows. When an application uses BigInteger.modPow() with a negative exponent (e.g., code ported from Python's pow(k, -1, q) idiom) in a DSA-style signing flow, the resulting signature component s is structurally valid (passes range checks) but mathematically incorrect, causing every downstream verifier to reject the signature silently. No exception is raised at signing time, making the failure difficult to detect. Confidentiality and integrity of key material are not directly compromised; the vulnerability does not affect jsrsasign's own built-in DSA.signWithMessageHash() or ECDSA signing functions, which use modInverse() internally (GitHub Gist, Snyk).

A proof-of-concept analysis document and code samples are publicly available via a GitHub Gist authored by the discoverer (Kr0emer), though Feedly's analysis classifies it as an advisory rather than a weaponized exploit — it contains no runnable attack payloads targeting a real deployment. There is no confirmed in-the-wild exploitation and the vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.042% (24th percentile), indicating low near-term exploitation probability. The CVSS v4.0 exploit maturity is rated "Proof of Concept" (Snyk, GitHub Gist).

1. Identify vulnerable targets: Search for Node.js applications that depend on jsrsasign versions ≤ 11.1.0 (e.g., via npm list jsrsasign or dependency scanning tools like Snyk or Dependabot).
2. Identify vulnerable code patterns: Look for application code that calls BigInteger.modPow() with a negative exponent — particularly code ported from Python using the pow(base, -1, mod) idiom for computing modular inverses.
3. Craft the malicious call: Trigger or supply input that causes the application to invoke k.modPow(new BigInteger('-1', 10), q), which silently returns 1 (Mode A) instead of the correct modular inverse.
4. Observe silent failure: The application proceeds to compute a DSA-style signature component s = k_inv * (hash + priv * r) mod q using the wrong k_inv = 1, producing a structurally valid but mathematically incorrect signature with no error raised.
5. Achieve DoS: All downstream verifiers reject the malformed signature, causing a persistent signature verification failure (Denial of Service) for any system relying on that signing flow (GitHub Gist).

• Logs: Application logs showing repeated signature verification failures with no corresponding signing errors; absence of exceptions during signing operations that produce invalid signatures.
• Code/Dependency: Presence of jsrsasign versions ≤ 11.1.0 in package.json or package-lock.json; source code containing calls to BigInteger.modPow() with a negative exponent literal (e.g., new BigInteger('-1', 10)).
• Behavioral: Consistent rejection of signatures by verifiers despite successful signing operations; authentication or integrity-check failures in systems using jsrsasign for DSA-style signing.

The primary remediation is to upgrade jsrsasign to version 11.1.1 or later, which includes the fix merged in commit 5ea1c32 (GitHub Commit). As an immediate workaround for code that cannot be upgraded, replace any call to BigInteger.modPow(new BigInteger('-1', 10), m) with BigInteger.modInverse(m), and replace a.modPow(-k, p) with a.modPow(k, p).modInverse(p). Developers should audit all codebases — especially those ported from Python — for use of negative exponents in modPow calls (Snyk, GitHub Gist).

The vulnerability was discovered and reported by researcher Kr0emer, who also submitted the fix via GitHub PR #650, which was merged by the jsrsasign maintainer (kjur) on February 20, 2026. Red Hat tracked the issue via Bugzilla (Bug 2450206) with high severity. Social media coverage included posts on Bluesky and Mastodon, and the vulnerability was picked up by aggregators including VulDB, cvefeed.io, and INCIBE-CERT. Community reaction was moderate, with the primary concern being the silent nature of the failure — no exception is raised, making the bug particularly insidious in production environments (Red Hat Bugzilla, GitHub PR).