Over the last 22 months, /wp-content/uploads/2025/03/blog-10.png has been working on a vulnerability which affected BitcoinJS, a popular package for the browser based generation of cryptocurrency wallets, as well as products and projects built from this software. Over a period of years, this vulnerability caused the generation of a significant number of vulnerable cryptocurrency wallets.
The source of the vulnerability is the SecureRandom() function found in the JSBN javascript library, combined with weaknesses that existed in major browser implementations of Math.random(). The JSBN library was utilized by BitcoinJS until March of 2014. Other projects incorporated early versions of BitcoinJS for the generation of Bitcoin and other cryptocurrency wallets. As such, it is difficult to calculate the exact time frame for the vulnerability, but we have observed vulnerable wallets being generated from 2011-2015. We can confirm that this vulnerability is exploitable, however, the amount of work necessary to exploit wallets varies significantly and, in general, considerably increases over time. That is to say, as a rule, impacted wallets generated in 2014 are substantially more difficult to attack than impacted wallets generated in 2012.
We have been coordinating disclosure with multiple entities and, as a result, millions of users have been alerted. In the event that it is possible an individual has assets held in an affected wallet, they should be moved to a newly generated wallet created with trusted software.
Vulnerability
In January of 2022, /wp-content/uploads/2025/03/blog-10.png was performing work for a customer that was locked out of a Blockchain.com (previously Blockchain.info) Bitcoin wallet. While examining this wallet, and avenues for recovery, it led us to (re)discover a potential issue in wallets generated by BitcoinJS (and derivative projects) between 2011 – 2015. This potentially affects millions of cryptocurrency wallets that were generated in the 2011-2015 timeframe. The value of assets still in those wallets is sizable. /wp-content/uploads/2025/03/blog-10.png engaged affected parties and has been working for over a year on remediating the issue. We weren’t, however, the first ones to notice this.
BitcoinJS (or bitcoinjs-lib) is a JavaScript implementation of Bitcoin. The first block of the Bitcoin blockchain was minted in January of 2009. The first BitcoinJS commit was a little over two years later in May of 2011.
You can view the 0.1.3 version here – https://cdnjs.cloudflare.com/ajax/libs/bitcoinjs-lib/0.1.3/bitcoinjs-min.js
Unfortunately, for an incredibly popular library, there was an issue in BitcoinJS.
On the 6th of April, 2018, an individual calling themselves “Ketamine” sent an email from <[email protected]> to the bitcoin-dev mailing list titled, “Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.” In this post, the user states:
“A significant number of past and current cryptocurrency products
contain a JavaScript class named SecureRandom(), containing both
entropy collection and a PRNG. The entropy collection and the RNG
itself are both deficient to the degree that key material can be
recovered by a third party with medium complexity.”
And goes on to say:
“The most common variations of the library attempts to collect entropy
from the window. crypto’s CSPRNG, but due to a type error in a comparison,
this function is silently stepped over without failing. Entropy is
subsequently gathered from math. Random (a 48-bit linear congruential
generator, seeded by the time in some browsers), and a single
execution of a medium resolution timer. In some known configurations
this system has substantially less than 48 bits of entropy.”
In the same mailing list thread, Mustafa Al-Bassam (also known as “tflow” from LulzSec) comments:
“In practice though, this doesn’t really matter, because navigator.appVersion < “5” returns true anyway for old browsers. The real issue is that modern browsers don’t have window.crypto.Randomly defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be using a CSPRNG when run on a modern browser.”
He appears to be referencing the piece of code below: