CVE-2026-4600 is a high severity (CVSS 7.4) signature verification flaw in jsrsasign, the JavaScript crypto library. Versions before 11.1.1 accept DSA parameters that make forged signatures and certificates verify. Upgrade to 11.1.1 or later, and stop trusting DSA keys from untrusted sources.
What's affected
The NVD record says versions of the npm package jsrsasign before 11.1.1 are vulnerable. Snyk's advisory for the npm package gives the same range, all versions earlier than 11.1.1, with 11.1.1 as the fixed version. The record also lists a WebJars copy of the package and a Red Hat erratum (RHSA-2026:19375), which means the library may reach you through other packaging than npm.
The affected code is the DSA public key import in KJUR.crypto.DSA.setPublic and the DSA and X.509 verification flow in src/dsa-2.0.js. The vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. Attack complexity is rated high, because an application has to be verifying DSA signatures or certificates built from attacker supplied keys.
The upstream pull request that carries the fix was merged into the project's master branch on 20 February 2026. The pull request page itself does not name a release, so the fixed version comes from the NVD record and Snyk.
How to check if you're exposed
- List the installed version in each project:
npm ls jsrsasign
- For Yarn or pnpm, use
yarn why jsrsasignorpnpm why jsrsasign. Check lockfiles too, since the library often arrives as a transitive dependency. - Search your code for the calls named in the record, such as X509.verifySignature and DSA keys. If you never verify DSA signatures or certificates with this library, your practical exposure is low.
- Check Java projects for the WebJars package, and check Red Hat based systems against the erratum.
- Run the free scan at gold.safeguard.sh/scan to list every copy across your dependencies.
What to do now
- Upgrade jsrsasign to 11.1.1 or later in every project and rebuild.
- Regenerate lockfiles and confirm nothing else pins an older copy.
- If you validate certificates with this library, prefer RSA or ECDSA keys and reject DSA certificates you do not need.
- Do not treat a certificate as trusted only because it passed this library's check if it came from an untrusted party. Check the chain against a trusted store.
- Add a dependency scan to your pull request checks so the next advisory is caught early.
Why it matters
The class is CWE-347, improper verification of a cryptographic signature. DSA verification rests on public parameters, and the fix description explains that the library accepted parameters without checking them against the rules DSA requires. With degenerate values, the verification equation holds for any message hash, so a signature check says yes when it should say no.
The fix validates the public key at import time. It checks that the group parameters are in range and that the generator has the right order, and it rejects bad keys with an error. A clean version bump gives you that check without changing your own code.
Signature checks are a trust decision. When the check is wrong, everything built on it, such as a signed token or a certificate chain, loses its meaning without any visible error. The record's KEV flag is false and neither source says it is exploited in the wild, but a public write up exists, so patch soon.
Try it yourself
See how a dependency inventory shows you which projects pull in a library like this one.
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I only use jsrsasign for RSA or ECDSA?
The record describes the flaw in DSA parameter handling, so those code paths are not the ones named. Upgrading is still the right move, and it also covers the companion CVE-2026-4601.
Is CVE-2026-4600 exploited in the wild?
The KEV flag is false and none of the pages I read say it is exploited. Treat it as a patch soon item.
Which version fixes it?
Version 11.1.1, according to the NVD record and Snyk. Confirm against the project's release notes before you ship.
Sources
Last reviewed: 19 October 2026.
