CVE-2026-4600: 
JavaScript vulnerability analysis and mitigation

CVE-2026-4600 is a cryptographic signature forgery vulnerability in the jsrsasign JavaScript cryptographic library affecting all versions before 11.1.1. The flaw resides in the DSA domain-parameter validation within KJUR.crypto.DSA.setPublic() (and the related DSA/X509 verification flow in src/dsa-2.0.js), allowing an attacker to forge DSA signatures or X.509 certificates that X509.verifySignature() accepts without any valid private key. It was disclosed on February 16, 2026, published to NVD on March 23, 2026, and credited to researcher Kr0emer. It carries a CVSS v3.1 base score of 9.1 (Critical) (Snyk Advisory, Red Hat Bugzilla).

The root cause (CWE-347: Improper Verification of Cryptographic Signature) is that KJUR.crypto.DSA.setPublic() accepted DSA public key parameters without enforcing FIPS 186-4 §4.7 domain-parameter constraints — specifically, it did not verify that g > 1, g^q ≡ 1 (mod p), or y > 1. DSA verification computes v = (g^u1 · y^u2 mod p) mod q and checks v == r; when an attacker supplies g=1 and y=1, both exponentiation terms collapse to 1 for any exponent, making v = 1 regardless of the message hash. Setting r=1 in the forged signature then trivially satisfies the check for every possible hash value, requiring no brute force or collision. The attack is exploitable over the network with no authentication or user interaction required, targeting any application that processes attacker-supplied DSA public keys or X.509 certificates (PoC Gist, GitHub PR #646).

Successful exploitation allows an unauthenticated remote attacker to forge DSA signatures and X.509 certificates that jsrsasign accepts as valid, completely undermining the integrity and confidentiality guarantees of any system relying on the library for signature verification. Attack scenarios include acceptance of forged self-signed or CA certificates, impersonation in federated identity or JWS flows with embedded keys, and bypassing code or data integrity checks in "bring your own key" verification flows. A single forged signature with r=1 and any invertible s verifies against all message hashes under the malicious parameters, meaning no per-message effort is needed by the attacker (PoC Gist, Snyk Advisory).

A public proof-of-concept exploit (runnable JavaScript) was published by researcher Kr0emer on February 16, 2026, demonstrating construction of a malicious X.509 certificate with g=1 parameters that X509.verifySignature() accepts (PoC Gist). The CVSS v4.0 exploit maturity is rated "Proof of Concept." As of the time of reporting, there is no evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.012% (2nd percentile), reflecting low current exploitation probability (Snyk Advisory).

1. Identify target: Locate applications using jsrsasign versions before 11.1.1 for DSA signature or X.509 certificate verification, particularly those accepting attacker-supplied public keys or certificates (e.g., JWS with embedded keys, federated identity endpoints, peer-provided certificate flows).
2. Craft malicious DSA parameters: Construct DSA domain parameters with g=1 (and optionally y=1), which collapse the verification equation to v=1 for any message hash. Use small or standard-sized parameters (e.g., p=23, q=11, g=1, y=1 for PoC; standard 1024/160-bit or 2048/256-bit for real attacks).
3. Build forged signature: Create a DSA signature with r=1 and any value of s that is invertible mod q. No knowledge of the private key is required.
4. Construct malicious X.509 certificate: Assemble a DER-encoded X.509 certificate embedding the malicious DSA SubjectPublicKeyInfo (with g=1 parameters) and the forged signature (r=1, s=any), as demonstrated in the public PoC using jsrsasign's own ASN.1 DER primitives.
5. Submit to target: Supply the forged certificate or signature to the target application's verification endpoint. X509.verifySignature() or KJUR.crypto.DSA.verifyWithMessageHash() will return true for any message hash, granting the attacker full signature bypass.
6. Achieve objective: Depending on the application, this enables impersonation of trusted entities, bypassing authentication, injecting malicious code or data that passes integrity checks, or establishing unauthorized trust relationships (PoC Gist, GitHub PR #646).

• Network: Unexpected or externally-sourced X.509 certificates or JWS tokens using DSA signature algorithms submitted to verification endpoints; certificates with unusually small DSA parameter values (e.g., p, q, g values of only a few bytes in ASN.1 encoding).
• Logs: Application logs showing successful DSA signature or certificate verification for certificates issued by unknown or self-signed CAs with DSA keys; repeated verification successes from untrusted or external certificate sources.
• File System: Presence of X.509 certificate files with DSA parameters where g=1 or y=1 (detectable by parsing the SubjectPublicKeyInfo field); unexpected certificate files in application trust stores.
• Process/Application Behavior: X509.verifySignature() returning true for certificates from untrusted issuers; applications accepting DSA-signed JWS tokens from unrecognized key sources without error (PoC Gist).

The primary remediation is to upgrade jsrsasign to version 11.1.1 or later, which adds strict FIPS 186-4 §4.7 domain-parameter validation in setPublic(), rejecting keys where g ≤ 1, y ≤ 1, or g^q mod p ≠ 1 (GitHub Commit, Snyk Advisory). As a workaround where immediate upgrade is not possible, applications should reject any externally-supplied DSA public keys or X.509 certificates before passing them to jsrsasign, and restrict verification to certificates from a pre-validated, trusted set. Organizations should also audit any systems that relied on DSA signature verification via this library during the vulnerable period to determine whether malicious certificates or signatures may have been accepted (Red Hat Bugzilla).

The vulnerability was assigned and disclosed by Snyk, with the fix contributed directly by the discovering researcher (Kr0emer) via GitHub pull request #646, which was merged by the jsrsasign maintainer on February 20, 2026 (GitHub PR #646). Red Hat tracked the issue via Bugzilla with a high severity rating (Red Hat Bugzilla). Community coverage appeared across vulnerability aggregators including ENISA EUVD, VulDB, and CVEFeed shortly after NVD publication on March 23, 2026, and a LinkedIn post noted the issue in May 2026. No major vendor statements beyond Red Hat or significant social media controversy have been observed.