Skip to main content
CybersecurityVulnerability Management

Weak RSA Keys Exposed in Widespread Use

Dimly lit server room with rows of computer servers, cables, and softly glowing screens displaying code amidst shadows.

“The badkeys project is an open-source service that checks public keys for known vulnerabilities.”

How Hanno and the badkeys dataset discovered an unexpected pattern

The discovery began with a large-scale collection effort. Hanno gathered a massive number of real-world public keys from Certificate Transparency logs, internet-wide TLS and SSH scans, PGP keys, and “many others,” and fed them into the badkeys project — an open-source service that checks public keys for known vulnerabilities. By searching that dataset for unexpectedly sparse RSA moduli, the analysis turned up a substantial set of keys in the wild that shared an unusual structure: moduli punctuated by regularly spaced blocks made entirely of zero bits, interleaved with blocks of seemingly random data.

Pattern 1: certificates with zero-filled blocks tied to Yahoo, Verizon, and NetApp devices

One of the two recurring patterns — described in the source as “Pattern 1” — appears in Certificate Transparency (CT) logs for certificates issued to several large organizations, explicitly including Yahoo and Verizon. The same pattern also shows up on some devices running NetApp software. The certificates exhibiting Pattern 1 have already expired, and the researchers shared their findings with the companies named; they attempted to learn which product generated the keys but did not receive a reply identifying a responsible product.

Pattern 2: SSH hosts running CompleteFTP and specific affected versions

Pattern 2 occurs on SSH hosts running the CompleteFTP software from EnterpriseDT. The underlying vulnerability is tied to specific product versions: RSA keys generated by CompleteFTP versions 10.0.012.0.0 (dated Dec 2016–Mar 2019) and DSA keys generated with v10.0.023.0.4 (dated Dec 2016–Dec 2023) exhibit the problematic structure. In short, the code paths that produced keys in those version windows produced moduli with repeated zero blocks rather than fully random material.

Scale and cryptanalytic implications of sparse moduli

The researchers characterize these vulnerabilities as affecting “a small minority of hosts on the internet,” but they highlight a second, more consequential point: independent cryptographic implementations failed in similar ways. The recurrence of the same structural failure across different software and devices suggests that more implementations could harbor the same bug. Because the weakness is structural — sparsity in the modulus — it invites specialized cryptanalytic approaches; the authors argue it is worth tailoring factoring and cryptanalysis algorithms specifically to exploit this failure mode.

What this means for technologists, affected enterprises, and adversaries

  • Technologists and security teams: Use tools like the badkeys project to scan public keys and internal inventories for moduli with repeated zero blocks; the dataset and detection approach that found these keys came from exactly that scanning and pattern-searching exercise.
  • Affected enterprises and procurement leaders: Review certificates and SSH keys issued or generated by vendors and devices named in the findings — notably CompleteFTP (see the version and date ranges above), NetApp devices, and certificates tied to the CT entries that included Yahoo and Verizon — and replace or reissue keys where necessary. The researchers reported that the certificates they found bearing Pattern 1 have already expired; nonetheless, confirmation of device and product inventories is required.
  • Adversaries and cryptanalysts: The repetition of the same bug across independent implementations creates an opportunity and a warning: opportunistic attackers could prioritize targets that expose sparse moduli, and cryptanalysts should consider algorithms optimized for moduli containing long zero blocks.

The technical takeaway is concise: badly formed key generation can and does appear in public, observable infrastructure, and when different implementations fail in the same structural way it changes the calculus for both defenders and attackers. The finding here rests on concrete evidence — CT log entries, SSH hosts, product-version windows, and device types — and it carries an operational imperative: find any remaining keys that match the zero-block patterns, identify the generating products and versions, and replace vulnerable keys. The broader open question the researchers raise is whether other implementations carry the same subtle bug; the recommended response is targeted detection and, where necessary, key replacement.

https://www.schneier.com/blog/archives/2026/06/factoring-rsa-keys-with-many-zeros.html