EUVD-2026-58182
GHSA-vh45-f885-3848
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
AC:H because the attacker must observe same-process Math.random() outputs and estimate generation time; PR:N/UI:N as no auth or victim action is needed; C:H/I:H for key recovery and signature forgery, A:N.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
sm-crypto provides JavaScript implementations of the Chinese cryptographic algorithms SM2, SM3, and SM4. Prior to 0.5.0, the default no-argument sm2.generateKeyPairHex() path in Node.js uses the module-wide SecureRandom instance in src/sm2/utils.js, supplied by jsbn@1.1.0, which seeds an ARC4 stream from Math.random() and new Date().getTime() because window.crypto.getRandomValues is unavailable even though globalThis.crypto exists. An attacker who can observe the process's Math.random() outputs and estimate the key-generation time can reconstruct the seed, recover generated SM2 private keys, and predict signing ephemeral scalars used to forge signatures. This issue is fixed in version 0.5.0.
Articles & Coverage 2
AnalysisAI
Predictable SM2 private-key and signing-nonce generation in the sm-crypto npm library (versions prior to 0.5.0) lets an attacker recover keys generated in Node.js. Because jsbn's SecureRandom checks window.crypto rather than Node's globalThis.crypto, the default sm2.generateKeyPairHex() falls back to seeding an ARC4 stream from Math.random() and the wall clock, so an adversary who observes a few Math.random() outputs and estimates the generation time can reconstruct private keys and forge signatures. Publicly available exploit code exists (reproduced end-to-end against the real npm packages), but no public exploit is identified as being used in active attacks and there is no CISA KEV listing.
Technical ContextAI
sm-crypto implements the Chinese national cryptographic algorithms SM2 (elliptic-curve), SM3 (hash), and SM4 (block cipher) in JavaScript. The flaw is a classic CWE-338 (use of a cryptographically weak PRNG) issue rooted in a dependency mismatch: src/sm2/utils.js instantiates a single module-wide SecureRandom from jsbn@1.1.0, and jsbn's RNG initialization branches on typeof window !== 'undefined' && window.crypto. In Node.js - sm-crypto's primary runtime - window is undefined, so the CSPRNG branch (window.crypto.getRandomValues) is skipped and the ARC4 seed pool is instead filled from Math.floor(65536*Math.random()) plus new Date().getTime() via rng_seed_time(). V8's Math.random() is a xorshift128+ generator whose internal state is recoverable from a small number of consecutive outputs, and the millisecond timestamp is estimable, so the entire seed - and every SM2 private key and ephemeral signing scalar derived from it - becomes reconstructable. Node does expose Web Crypto as globalThis.crypto, but because jsbn only probes window.crypto the secure path is never taken. The affected package is identified by cpe:2.3:a:juneandgreen:sm-crypto.
RemediationAI
Upgrade to the fixed release: Vendor-released patch: sm-crypto 0.5.0, which changes SM2 random-number generation to use Node's crypto module (per the CHANGELOG and commit 1f9bd7bd160c24efd9c26c8f7fda997c68c823d0). After upgrading, treat any SM2 key pair or signing key previously generated by a vulnerable version in Node.js as compromised: regenerate those keys and re-issue or re-sign anything depending on them, since the upgrade does not retroactively secure already-generated secrets. If an immediate upgrade is not possible, the specific compensating control is to stop using the default no-argument sm2.generateKeyPairHex() path and instead supply your own cryptographically secure random value - generate the private key with Node's crypto.randomBytes/webcrypto and pass it into generateKeyPairHex rather than relying on the module-wide jsbn SecureRandom; the trade-off is code changes at every key- and signature-generation call site plus review to ensure no ephemeral signing scalars still flow through the weak RNG. Refer to the advisory at https://github.com/JuneAndGreen/sm-crypto/security/advisories/GHSA-vh45-f885-3848 and the patch commit https://github.com/JuneAndGreen/sm-crypto/commit/1f9bd7bd160c24efd9c26c8f7fda997c68c823d0.
A vulnerability in the NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could
FortiOS and FortiProxy contain an authentication bypass via the Node.js websocket module allowing unauthenticated remote
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Eval injection vulnerability in the internals.batch function in lib/batch.js in the bassmaster plugin before 1.5.2 for t
Flowise version 3.0.5 contains a remote code execution vulnerability in the CustomMCP node. The mcpServerConfig paramete
Node.js 8.5.0 before 8.6.0 allows remote attackers to access unintended files, because a change to ".." handling was inc
An issue was discovered in the node-serialize package 0.0.4 for Node.js. Rated critical severity (CVSS 9.8), this vulner
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
Directory traversal vulnerability in the st module before 0.2.5 for Node.js allows remote attackers to read arbitrary fi
Multiple SQL injection vulnerabilities in the Manage Accounts page in the AccountManagement.asmx service in the Solarwin
The JS-YAML module before 2.0.5 for Node.js parses input without properly considering the unsafe !!js/function tag, whic
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today