How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

363,159

Total vulnerabilities in the database

sm-crypto: Predictable SM2 key generation in Node.js: default RNG uses Math.random + wall clock — sm-crypto

Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)

Summary

sm-crypto (npm package 0.4.0, the latest release, published 2026-01-20) generates SM2 private keys and signing ephemeral scalars from a single module-wide RNG instance (src/sm2/utils.js: const rng = new SecureRandom()). SecureRandom is jsbn's PRNG, which seeds an ARC4 stream from window.crypto.getRandomValues when available. In Node.js — sm-crypto's primary runtime — window is undefined, so the CSPRNG branch is skipped and the seed pool is instead filled from Math.random() (V8 xorshift128+, recoverable from a few outputs) plus new Date().getTime() (wall clock, attacker-estimable).

Node does expose Web Crypto as globalThis.crypto, but jsbn checks window.crypto, not globalThis.crypto, so the secure path is never taken. Consequently every SM2 private key produced by the default sm2.generateKeyPairHex() and every signing ephemeral scalar is derived from non-cryptographic sources and is predictable by an attacker who can observe a few Math.random() outputs and estimate the generation time.

This is the library's default (no-argument) path; no caller-selected parameter or configuration is required to trigger it. It is reproduced end-to-end against the unmodified real npm packages ([email protected] + [email protected]); the PoC below runs against the real installed package, not a copy. The defect is still present on the latest published version (0.4.0) and is not covered by any existing JuneAndGreen/sm-crypto issue (0 afldl issues exist; the most recent issues are unrelated SM3/HKDF/PBKDF2 feature requests).

Details

[email protected] index.js — RNG pool initialization (fallback taken in Node):

if (rng_pool == null) {
  rng_pool = new Array(); rng_pptr = 0; var t;
  if (typeof window !== &quot;undefined&quot; &amp;&amp; window.crypto) {     // &lt;-- false in Node
    if (window.crypto.getRandomValues) { /* webcrypto */ }
    ...
  }
  while (rng_pptr &lt; rng_psize) {                            // &lt;-- fallback path
    t = Math.floor(65536 * Math.random());                  //     Math.random()
    rng_pool[rng_pptr++] = t &gt;&gt;&gt; 8;
    rng_pool[rng_pptr++] = t &amp; 255;
  }
  rng_pptr = 0;
  rng_seed_time();                                           //     + Date.getTime()
}

sm-crypto src/sm2/utils.js:

const { SecureRandom } = require(&#039;jsbn&#039;);
const rng = new SecureRandom();                              // single module-wide RNG
...
function generateKeyPairHex(a, b, c) {
  const random = a ? new BigInteger(a, b, c)
                   : new BigInteger(n.bitLength(), rng);     // uses rng
  const d = random.mod(n.subtract(BigInteger.ONE)).add(BigInteger.ONE); // private key
  ...
}

The default (no-argument) call path uses rng, the jsbn ARC4 instance seeded from Math.random() + time. The same rng feeds the signing ephemeral scalar during SM2 signing.

PoC

The PoC runs against the real installed npm packages. It pins Math.random and Date before require('sm-crypto') so jsbn's seed pool is built from controlled inputs. Three independent fresh Node processes then produce the same SM2 private key, proving the key is a pure deterministic function of those non-cryptographic sources. It also prints a probe confirming the fallback branch is taken in Node.

One-line reproducer

WORK=$(mktemp -d) &amp;&amp; cd &quot;$WORK&quot; &amp;&amp; npm init -y &gt;/dev/null \
  &amp;&amp; npm install [email protected] [email protected] &gt;/dev/null \
  &amp;&amp; export NODE_PATH=&quot;$WORK/node_modules&quot; \
  &amp;&amp; node poc.js probe &amp;&amp; node poc.js deterministic &amp;&amp; node poc.js deterministic

`poc.js`

/*
 * PoC for sm-crypto predictable default RNG in Node.js.
 *
 * sm-crypto (npm 0.4.0) generates SM2 private keys / ephemeral scalars using
 * jsbn&#039;s SecureRandom. In a browser jsbn seeds ARC4 from window.crypto, but in
 * Node.js `window` is undefined so the CSPRNG branch is skipped and the pool is
 * filled from Math.random() plus new Date().getTime(). Both are
 * non-cryptographic; the time is attacker-estimable and V8&#039;s Math.random is a
 * recoverable xorshift128+ stream. Consequently SM2 keys produced by the
 * default path are predictable.
 *
 * This PoC proves the key is a deterministic function of those two inputs: we
 * pin Math.random and the clock to fixed values BEFORE sm-crypto (and therefore
 * jsbn) is loaded, then generate a keypair. Re-running with the same pinned
 * values reproduces the exact same private key.
 */

const MODE = process.argv[2] || &#039;probe&#039;; // &#039;probe&#039; | &#039;deterministic&#039;

if (MODE === &#039;deterministic&#039;) {
  // --- pin entropy sources BEFORE requiring sm-crypto/jsbn ---
  const fixedTime = 1700000000000;
  let s = 0x12345678 &gt;&gt;&gt; 0;
  Math.random = function () {
    // tiny deterministic LCG standing in for the (already non-crypto) Math.random
    s = (Math.imul(s, 1103515245) + 12345) &gt;&gt;&gt; 0;
    return s / 0x100000000;
  };
  const RealDate = globalThis.Date;
  class FixedDate extends RealDate {
    constructor(...a) { super(...(a.length === 0 ? [fixedTime] : a)); }
  }
  FixedDate.now = () =&gt; fixedTime;
  globalThis.Date = FixedDate;
}

const sm2 = require(&#039;sm-crypto&#039;).sm2;
const kp = sm2.generateKeyPairHex();
console.log(&#039;PRIVATE=&#039; + kp.privateKey);

if (MODE === &#039;probe&#039;) {
  console.log(&#039;--- probe ---&#039;);
  console.log(&#039;typeof window =&#039;, typeof window, &#039;(undefined in Node =&gt; jsbn CSPRNG branch skipped)&#039;);
  console.log(&#039;typeof globalThis.crypto =&#039;, typeof globalThis.crypto, &#039;(Node Web Crypto exists but jsbn checks window.crypto, not globalThis.crypto)&#039;);
  console.log(&#039;Math.random sample =&#039;, Math.random());
  console.log(&#039;Date.now() =&#039;, Date.now(), &#039;(attacker-estimable, mixed into ARC4 seed)&#039;);
}

Real captured output:

===== PROBE (real default path, no patching) =====
PRIVATE=6072e45733a4187791ec28ce906fef18c7d33c8529969e1a852833c4349cfc38
--- probe ---
typeof window = undefined (undefined in Node =&gt; jsbn CSPRNG branch skipped)
typeof globalThis.crypto = object (Node Web Crypto exists but jsbn checks window.crypto, not globalThis.crypto)
Math.random sample = 0.704452488761137
Date.now() = 1784455686795 (attacker-estimable, mixed into ARC4 seed)

===== DETERMINISTIC (Math.random + Date pinned before require sm-crypto) =====
--- run #1 ---  PRIVATE=143268fa0939b4da09eab8c9a2e027a04555b6c433fef4f54fc5edd517c0a6b1
--- run #2 ---  PRIVATE=143268fa0939b4da09eab8c9a2e027a04555b6c433fef4f54fc5edd517c0a6b1

The two deterministic runs produce the identical SM2 private key, demonstrating the key is a pure function of Math.random() + wall-clock time.

Impact

Private-key recovery / signature forgery of any SM2 keypair generated with the default API in Node.js. This is the most serious class of defect for a maintained SM2 library: the default key-generation path is non-cryptographic on its primary runtime.

Private-key recovery. Any SM2 keypair generated with the default API in Node is derived from Math.random() + wall-clock time. An attacker who can observe a few Math.random() outputs (V8 xorshift128+ state is recoverable from ~4 observed doubles) and estimate the generation time can reproduce the private key and forge signatures.
Signing ephemeral reuse / forgery. The same RNG feeds the ephemeral scalar k during SM2 signing; a predictable k leaks the private key from a single signature (SM2 is EC-Schnorr-like: s = (k^-1)(e + d·r) mod n).
Pre-authentication / no privilege required: anyone who can induce a victim to generate a key or sign a message (the normal API use) is positioned to predict the secret material.

Suggested fix

Seed the RNG from a CSPRNG in Node. The simplest fix in sm-crypto is to replace the jsbn ARC4 instance with Web Crypto / crypto.randomBytes:

// src/sm2/utils.js
const nodeCrypto = (typeof require === &#039;function&#039;) ? require(&#039;crypto&#039;) : null;
function csrandBytes(n) {
  if (nodeCrypto) return nodeCrypto.randomBytes(n);          // Node
  if (globalThis.crypto) {                                   // Web Crypto (browser/Node ≥ 19)
    const b = new Uint8Array(n); globalThis.crypto.getRandomValues(b); return b;
  }
  throw new Error(&#039;no CSPRNG available&#039;);
}

and use it to generate the private key / ephemeral directly, or to reseed the jsbn pool. A separate (upstream) fix belongs in jsbn to check globalThis.crypto in addition to window.crypto.

Affected versions

npm sm-crypto 0.4.0 (latest, published 2026-01-20). Depends on jsbn ^1.1.0 ([email protected], whose index.js RNG is the root cause).
Runtime: Node.js (the primary runtime; in a browser the jsbn CSPRNG branch is taken).

Credit

Reported by the diff/ambidiff security research effort (afldl).

Published: Jul 24, 2026
Updated: Jul 25, 2026
GHSA: GHSA-vh45-f885-3848
Severity: Critical
Exploit:
CISA KEV:

CVSS v3:

Severity: Critical
Score: 9.1
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CWEs:

CWE-338

Affected Software
References

Software	From	Fixed in
sm-crypto	-	0.5.0

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.