CVE-2021-41117
A public proof of concept exists; no exploitation attested.
- Published2021-10-11
- Fixed in1.0.4
- WeaknessCWE-335
Am I affected?
Debian, Ubuntu or Red Hat sometimes backport a fix without changing the upstream version number: such a version reads « to verify », never « affected ».With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.
Description
keypair is a a RSA PEM key generator written in javascript. keypair implements a lot of cryptographic primitives on its own or by borrowing from other libraries where possible, including node-forge. An issue was discovered where this library was generating identical RSA keys used in SSH. This would mean that the library is generating identical P, Q (and thus N) values which, in practical terms, is impossible with RSA-2048 keys. Generating identical values, repeatedly, usually indicates an issue with poor random number generation, or, poor handling of CSPRNG output. Issue 1: Poor random number generation (`GHSL-2021-1012`). The library does not rely entirely on a platform provided CSPRNG, rather, it uses it's own counter-based CMAC approach. Where things go wrong is seeding the CMAC implementation with "true" random data in the function `defaultSeedFile`. In order to seed the AES-CMAC generator, the library will take two different approaches depending on the JavaScript execution environment. In a browser, the library will use [`window.crypto.getRandomValues()`](https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L971). However, in a nodeJS execution environment, the `window` object is not defined, so it goes down a much less secure solution, also of which has a bug in it. It does look like the library tries to use node's CSPRNG when possible unfortunately, it looks like the `crypto` object is null because a variable was declared with the same name, and set to `null`. So the node CSPRNG path is never taken. However, when `window.crypto.getRandomValues()` is not available, a Lehmer LCG random number generator is used to seed the CMAC counter, and the LCG is seeded with `Math.random`. While this is poor and would likely qualify in a security bug in itself, it does not explain the extreme frequency in which duplicate keys occur. The main flaw: The output from the Lehmer LCG is encoded incorrectly. The specific [line][https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L1008] with the flaw is: `b.putByte(String.fromCharCode(next & 0xFF))` The [definition](https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L350-L352) of `putByte` is `util.ByteBuffer.prototype.putByte = function(b) {this.data += String.fromCharCode(b);};`. Simplified, this is `String.fromCharCode(String.fromCharCode(next & 0xFF))`. The double `String.fromCharCode` is almost certainly unintentional and the source of weak seeding. Unfortunately, this does not result in an error. Rather, it results most of the buffer containing zeros. Since we are masking with 0xFF, we can determine that 97% of the output from the LCG are converted to zeros. The only outputs that result in meaningful values are outputs 48 through 57, inclusive. The impact is that each byte in the RNG seed has a 97% chance of being 0 due to incorrect conversion. When it is not, the bytes are 0 through 9. In summary, there are three immediate concerns: 1. The library has an insecure random number fallback path. Ideally the library would require a strong CSPRNG instead of attempting to use a LCG and `Math.random`. 2. The library does not correctly use a strong random number generator when run in NodeJS, even though a strong CSPRNG is available. 3. The fallback path has an issue in the implementation where a majority of the seed data is going to effectively be zero. Due to the poor random number generation, keypair generates RSA keys that are relatively easy to guess. This could enable an attacker to decrypt confidential messages or gain authorized access to an account belonging to the victim.
Timeline
dates in UTC- 2021-10-1117:15CVE publishedNVD
Versions per branch
NVD · OSV| Branch | Affected | Fixed in | Source |
|---|---|---|---|
| 1.0 | < 1.0.4 | 1.0.4 | NVD · OSV |
as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.
Fix
- Update Keypair project keypair to 1.0.4
Advisories and patches
- github.comPatch
Detection
read 2026-11-01 01:02 UTC- Nuclei template
- none so far ProjectDiscovery
- Exploit-DB
- no entry Exploit-DB
- Proof of concept
- PoC-in-GitHub1 repository, unverifiedknown since 2026-11-01badkeys/keypairvuln
- Metasploit modules
- none listed Metasploit Framework
Sources
- CNACVSS 3.18.7known since 2026-10-23
- NVDCVSS 3.19.1read 2026-10-23
- NVDCVSS 2.06.4read 2026-10-23
- CNAweakness (CWE)CWE-335known since 2026-10-23
- FIRST EPSSEPSS score3.2 %2026-11-08
- PoC-in-GitHubproof of concept1known since 2026-11-01
- OSVaffected packages—
- GitHub AdvisoriesadvisoryHIGH2021-10-11
Identifiers
- EUVD-2021-2147same flawENISA EUVD · LicenseRef-ENISA-legal-notice
- GHSA-3f99-hvg4-qjwjsame flawGitHub Advisory Database · CC-BY-4.0
Technical details
- CVSS v3 Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
- Published
- 2021-10-11
- Last Modified
- 2026-06-17
- NVD status
- Modified
- GitHub Advisory
- GHSA-3f99-hvg4-qjwj
Frequently asked questions
What is CVE-2021-41117?
Is CVE-2021-41117 actively exploited?
What is the CVSS score for CVE-2021-41117?
Running keypair? Hear about its next vulnerability
Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».
No credit card required · No monthly cap on website lookups · 250 API requests/month
Go further
- Following what attackers exploit right now? The CISA KEV additions of the month, with their patch deadlines.
- Running this software? Vulnerability monitoring alerts you to new vulnerabilities in your products.
Related vulnerabilities
Same product first, then the same vendor advisory and the same publication week.
Sources for this record
- CVE Program · CVE Program Terms of Use
- ENISA EU Vulnerability Database · ENISA legal notice §1.2 (reproduction authorised, provided the source is acknowledged)
- FIRST EPSS · EPSS terms of use (free use, attribution requested)
- GitHub Advisory Database · CC-BY-4.0 · GHSA-3f99-hvg4-qjwj
- NVD · Public domain (17 U.S.C. § 105) for NVD-authored data; third-party content under its own terms
- OSV.dev · Per record, as its publisher states it: each row carries the label in sourceLicense when one is served
- PoC-in-GitHub · CC0-1.0