Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes

A serious random-number-generation weakness discovered in COLDCARD hardware-wallet firmware has raised concerns that Bitcoin wallet seeds generated by affected devices may be predictable under certain conditions. The vulnerability has also been linked by researchers to a rapid transfer of more than 1,000 Bitcoin, valued at approximately $70 million at the time, although the available public evidence does not yet conclusively establish that the flaw was used in that specific incident. 

The case demonstrates one of the most fundamental realities of cryptocurrency security: a hardware wallet can protect a private key perfectly after it has been created, but that protection becomes largely irrelevant if the key was generated from insufficiently random information in the first place.

Bitcoin does not distinguish between a private key generated securely and one produced by a predictable process. Both appear to be mathematically valid keys and both can authorise transactions. The difference is that a securely generated key should be computationally impossible for an attacker to guess, while a weakly generated key may belong to a much smaller and searchable set of possibilities.

This makes the quality of random-number generation one of the most critical security properties of any cryptocurrency wallet.

The reported $70 million Bitcoin movement

On July 30, 2026, an unidentified entity reportedly transferred funds from 1,196 Bitcoin addresses within approximately 41 minutes. The transactions moved around 1,082.65 Bitcoin, worth roughly $70.2 million at the time.

Blockchain researchers observed similarities across the transactions, including a common fee rate and transaction structure, suggesting that they were probably initiated by a single operator or coordinated process.

However, blockchain evidence alone cannot determine whether the transfers represented theft, emergency migration by the legitimate owners or another coordinated movement of funds. A transaction created by an attacker using a recovered private key can look technically identical to a transaction authorised by the actual wallet owner.

Researchers associated the timing and transaction pattern with reports from COLDCARD users who claimed that funds had been removed from their wallets. This prompted further investigation into the firmware used to generate wallet seeds.

Block’s Bitcoin engineering and security teams, working with other researchers, identified an integration error affecting the source of randomness used by portions of the COLDCARD firmware. Their analysis concluded that some wallet seeds could have been generated from substantially less cryptographic entropy than users reasonably expected.

Nevertheless, no public analysis has yet demonstrated an end-to-end recovery of a specific victim’s seed and matched that seed to one of the addresses drained during the reported sweep. The relationship between the vulnerability and the transactions should therefore be treated as a serious and plausible link rather than a conclusively established attribution.

The flaw was introduced through an RNG integration error

The vulnerability reportedly originated from an error introduced when COLDCARD changed the software path used for generating wallet entropy in March 2021.

Earlier firmware called a function that obtained random bytes directly from the STM32 microcontroller’s hardware random-number generator. Following a firmware change, wallet generation instead used a random function provided through another software library.

The production configuration defined the hardware RNG option as disabled because COLDCARD supplied its own hardware-randomness wrapper. However, the external library checked only whether the configuration macro existed, rather than whether the macro was actually enabled.

Since the macro was present but set to zero, the build process succeeded and the library connected to MicroPython’s software fallback random-number generator instead of the intended hardware RNG.

This is an unusually instructive software-security failure because the individual pieces behaved largely as written. The problem emerged from the interaction between configuration logic, library assumptions and two different interpretations of the same compile-time setting.

One component interpreted the value zero as meaning that hardware randomness was disabled. Another component interpreted the mere existence of the setting as confirmation that hardware randomness was available.

The result was that security-sensitive code silently used a deterministic software generator in place of a cryptographically secure hardware source.

A single configuration check therefore undermined one of the most important security functions of the device. Software supply chains remain wonderfully efficient at converting one misplaced conditional statement into an international financial emergency.

Why a deterministic PRNG is dangerous

A pseudorandom number generator produces a sequence of values from an initial internal state known as a seed. A cryptographically secure generator uses unpredictable input and is designed so that observing some outputs does not allow an attacker to reconstruct previous or future values.

A deterministic non-cryptographic PRNG may still produce output that looks random during ordinary testing. The values may be well distributed and may not obviously repeat. However, if an attacker can reproduce or narrow down the initial state, the entire sequence can potentially be regenerated.

In the affected COLDCARD path, the software fallback reportedly used values derived from the microcontroller’s unique identifier and timing registers. These included the chip identifier, system timer and real-time clock state.

These values can introduce variation, but variation is not the same as cryptographic entropy. A device identifier is fixed and may be discoverable. Timer values may fall within predictable ranges, and multiple timing values may be correlated rather than independent.

Once the starting conditions and number of earlier random-number calls are known or sufficiently constrained, the resulting output stream may become reproducible.

An attacker would not necessarily need physical access to the target wallet at the time of attack. Candidate seeds could potentially be generated offline, corresponding Bitcoin addresses could be derived from those seeds and the addresses could then be compared with publicly available blockchain information.

The blockchain effectively provides a verification mechanism. When a generated candidate seed produces an address known to hold Bitcoin, the attacker has a strong indication that the correct seed or private key may have been found.

This is one reason weak randomness is particularly dangerous in cryptocurrency systems. Public keys and addresses are deliberately visible, allowing an attacker to test guesses without interacting with the victim’s device.

Earlier COLDCARD models may face greater exposure

The severity of the flaw varies according to the hardware model and the firmware used when the wallet seed was originally generated.

Researchers reported that COLDCARD Mk2 and Mk3 devices running affected version 4 firmware followed the vulnerable software-randomness path without adding cryptographically secure reseeding from a secure element.

For those devices, the generated output could be deterministic when the microcontroller identifier, timing state and random-number call history were known. Even when some of those values were not known, the possible candidate space could remain substantially smaller than the search space expected for a properly generated Bitcoin seed.

The affected Mk3 releases identified by Coinkite include firmware versions 4.0.1 through 4.1.9, with version 4.2.0 providing the correction. Independent research also places Mk2 and Mk3 version 4.0.0 through 4.1.9 on the vulnerable generation path.

Users should understand that the relevant firmware is the version running when the seed was created. Installing an affected version later does not weaken a seed originally generated safely, while upgrading today does not repair a seed that was previously created using vulnerable firmware.

Later models added entropy but reduced it to 32 bits

COLDCARD Mk4, Mk5 and Q devices reportedly added secure-element information to the random-number-generation process. This provided additional protection compared with the affected Mk2 and Mk3 path, but researchers found that the secure input was compressed and only four bytes were passed into the reseeding function.

Four bytes represent 32 bits of variation. For a fixed fallback state and execution history, this could limit the number of securely distinguished output streams to no more than 2³².

Approximately 4.3 billion possibilities may sound enormous in ordinary human terms, but it is far below the security level expected from modern cryptographic key generation. Specialised computing systems can search billions of candidates, particularly when an attacker can verify each candidate against known Bitcoin addresses.

The wider practical search space may be larger because the attacker may not know the device identifier, exact timing state or number of earlier calls to the random generator. Researchers therefore cautioned that the flaw does not imply that every wallet can be recovered instantly by any remote attacker.

Practical exploitation depends on how much information can be learned or inferred about the device and its operation. It also depends on the computational cost of deriving wallet addresses for each candidate and comparing them with blockchain data.

Even so, security should not depend on attackers being unable to estimate boot timing or device behaviour. Cryptographic random-number generation is supposed to provide security even when the algorithm, firmware and operating conditions are publicly understood.

Security through uncertainty about implementation details is not an acceptable replacement for genuine entropy.

Hashing does not create missing entropy

The affected wallet-generation process reportedly passed the generated random value through a cryptographic hash before producing the final seed.

Hashing can make output appear uniformly distributed, but it cannot create randomness that was not present in the input. If there are only 2³² possible input values, hashing those inputs can produce at most 2³² corresponding outputs, regardless of whether each output is 256 bits long.

This distinction is frequently misunderstood. The length of a generated key does not automatically determine its effective security.

A 256-bit private key generated from only 32 bits of true entropy does not provide 256 bits of protection. An attacker needs to search the smaller set of possible inputs rather than every mathematically valid 256-bit key.

The same principle applies to BIP-39 mnemonic words. A 12-word or 24-word recovery phrase may look like a normal wallet backup, but its security depends on the entropy used to select those words.

A checksum verifies that the phrase is structurally valid. It does not prove that the phrase was generated unpredictably.

Firmware upgrades cannot repair an existing seed

Coinkite has released corrected firmware for affected COLDCARD models and release tracks. However, installing the update only ensures that future secrets are generated through the corrected process.

An existing seed does not change when the firmware is upgraded. If the seed was created using vulnerable firmware, its original entropy remains exactly as weak or strong as it was at creation.

Restoring the same seed into an updated COLDCARD or another hardware wallet also does not solve the problem. The vulnerability belongs to the secret itself, not merely to the device currently storing it.

Users with potentially affected seeds must generate an entirely new seed using corrected firmware and transfer their funds to addresses derived from that new seed.

This migration must be carried out carefully. Users should first update the device, create and securely record the new recovery phrase, verify the backup, confirm the wallet fingerprint and receiving address, and send a small test transaction before transferring the remaining balance.

The old seed backup should be retained until the migration has been completed and the new wallet has been independently verified. Once the transfer is confirmed, the old seed should no longer be used to receive funds.

Affected firmware must be identified correctly

The firmware versions currently identified as affected vary by model and release channel. COLDCARD Mk3 seeds generated using versions 4.0.1 through 4.1.9 are considered at risk by Coinkite unless sufficient independent dice entropy was added. Version 4.2.0 or later contains the correction.

COLDCARD Mk4 and Mk5 users should upgrade to standard firmware version 5.6.0 or later, while COLDCARD Q users should install version 1.5.0Q or later. Users of Edge firmware require the corresponding corrected Edge release, including version 6.6.0X or later for Mk4 and Mk5 and version 6.6.0QX or later for Q.

Users should not compare only the numerical size of version numbers across different release tracks. A higher-looking Edge version is not necessarily corrected unless it is the specifically identified fixed release.

The relevant question is not simply which firmware is installed today, but which firmware was running when the wallet seed, paper-wallet key or other secret was generated.

This can be difficult for users who created wallets several years ago and no longer have accurate records. When the generation history cannot be established confidently, migrating to a newly generated seed is generally safer than assuming the original seed was unaffected.

Dice-generated entropy may provide protection

COLDCARD allows users to add physical dice rolls when generating a wallet seed. Coinkite states that a seed generated using at least 50 fair, independent and private dice rolls is not considered at risk from this RNG flaw alone.

The dice rolls supply entropy independently of the affected software-randomness path. When performed properly, they can restore sufficient unpredictability even if the device-generated random stream is weak.

However, this exception depends on the dice process being genuine. The rolls must have been independently generated, kept private and entered accurately. A user who does not remember how many rolls were used, reused a recorded sequence or followed an uncertain procedure should not assume that the seed is safe.

The incident demonstrates the value of combining independent entropy sources, particularly for high-value wallets. However, manual entropy is not a substitute for secure device design. Most users reasonably expect a hardware wallet to generate safe keys without requiring them to conduct a small casino operation at their desk.

A strong BIP-39 passphrase may reduce exposure

A BIP-39 passphrase creates a separate wallet from the same recovery phrase. An attacker who obtains only the base seed words would also need the exact passphrase to derive the protected wallet.

A sufficiently strong, unique and secret passphrase may therefore protect funds even when the underlying seed was generated through affected firmware.

However, short, common, reused, predictable or previously exposed passphrases do not provide reliable protection. Every possible passphrase creates a valid wallet, so an attacker can test candidate passphrases by deriving addresses and comparing them with public blockchain data.

Coinkite continues to recommend replacing affected seeds even when a strong passphrase was used. The passphrase may reduce immediate risk, but it does not correct the weak seed-generation process.

Passphrases also introduce operational risk. Losing the passphrase permanently prevents access to the wallet, and even a minor typographical difference produces an entirely different set of addresses.

Users adopting passphrases must store them separately from the recovery words and verify the wallet fingerprint before transferring funds. A passphrase should be treated as a critical secret, not as an optional password that can be reset through customer support after an unfortunate weekend.

Multisignature security depends on independent devices

Multisignature wallets require multiple keys to authorise transactions and can significantly reduce the consequences of a single compromised device.

However, multisignature does not automatically solve the COLDCARD entropy problem if all participating keys were generated using the same vulnerable process.

If an attacker can recover enough affected keys to satisfy the signing threshold, the wallet can still be compromised. A two-of-three wallet built entirely from similarly affected COLDCARD devices may therefore remain exposed.

Multisignature provides stronger protection when the required quorum includes keys generated independently on unaffected devices, different hardware architectures or securely generated offline systems.

This incident reinforces the importance of diversity in high-value custody arrangements. Using three devices from the same manufacturer with the same firmware family may protect against the physical loss of one device, but it may provide less protection against a shared implementation flaw.

True resilience requires avoiding common-mode failure, where a single vulnerability affects several supposedly independent security controls simultaneously.

Other generated secrets may also be affected

The vulnerable random-number stream was reportedly used for more than ordinary BIP-39 wallet seeds. Researchers identified other features that may have consumed randomness from the same source, including paper-wallet private keys, random Seed XOR masks, temporary cloning keys, USB encryption keys, Key Teleport secrets, Web2FA material, generated passwords and certain hardware security module values.

The severity differs between features, but the common issue is that all relied on the same limited or predictable random stream.

Paper-wallet keys may be especially concerning because the random output can be used directly as the private key. The corresponding public Bitcoin address gives attackers an immediate way to validate candidate keys.

Temporary encryption keys may expose captured transfer sessions even when they do not directly reveal the primary wallet seed. Predictable generated passwords or authentication values could weaken additional security functions.

Users and administrators should therefore review whether affected devices were used for purposes beyond ordinary wallet creation.

The incident is not merely about one recovery phrase. It demonstrates how a flawed randomness service can affect every security feature that quietly depends on it.

Hardware wallets remain valuable, but not infallible

The incident should not be interpreted as evidence that hardware wallets provide no security. Properly designed hardware wallets still offer substantial protection by isolating private keys, requiring physical confirmation and reducing exposure to malware on general-purpose computers.

However, hardware wallets are specialised computers and remain dependent on firmware, libraries, secure elements, microcontrollers, build configurations and manufacturing processes. Every one of these layers can contain implementation errors.

The term “cold wallet” describes connectivity and key-handling practices. It does not guarantee that every internal operation is cryptographically secure.

A wallet can remain completely offline while producing predictable keys. Air-gapping prevents network access, but it cannot add entropy to a deterministic random-number generator.

Likewise, a secure element can protect a secret from extraction, but it cannot make a weak secret stronger after generation. Security hardware protects what it is given. It does not retroactively improve the quality of the data placed inside it.

This is why hardware-wallet security must be evaluated across the entire key lifecycle, beginning with entropy generation and continuing through storage, transaction display, signing, backup, recovery and disposal.

Open-source code does not eliminate integration risk

COLDCARD publishes its firmware source, which allows independent researchers to inspect its design and verify important security claims.

Open-source availability is valuable, but it does not guarantee that every vulnerability will be discovered quickly. The RNG integration error reportedly remained in production code for several years despite the relevant configuration and library logic being publicly visible.

Complex security failures often occur between components rather than within a single obviously defective function. A reviewer may inspect the hardware RNG wrapper and find it secure, inspect the software generator and understand its limitations, yet still miss that the wallet-generation path is connected to the wrong implementation.

Effective review therefore requires testing the compiled production system rather than relying only on source-level intentions.

Build-time assertions should verify that security-critical dependencies resolve to the expected implementations. Runtime self-tests should confirm that hardware entropy is available and fail securely when it is not.

Cryptographic code should never silently fall back to a deterministic non-cryptographic generator when secure randomness is required. A failed hardware RNG should prevent seed generation rather than trigger a more convenient but unsafe alternative.

Randomness must be continuously tested and independently reviewed

Hardware-wallet manufacturers should implement architectural controls that make this class of error difficult to introduce.

Security-critical random-number generation should use a clearly defined interface with no ambiguous fallback. The code should fail closed if the approved entropy source is unavailable, misconfigured or returns invalid output.

Automated tests should verify that production builds invoke the correct hardware functions. These tests should operate on real compiled firmware and hardware, not merely on mocked source components.

Developers should also perform deterministic test builds under controlled conditions. If two supposedly independent device initialisations produce reproducible or suspiciously related output, the build should fail security validation.

Randomness testing must go beyond statistical appearance. A deterministic generator can pass many frequency and distribution tests while remaining completely predictable. Security analysis must trace the origin of entropy and calculate how much genuine unpredictability reaches the final key.

Independent audits should examine the full entropy pipeline, including hardware sources, configuration macros, library bindings, reseeding logic, state size and failure behaviour.

Firmware changes affecting key generation should receive particularly rigorous review because defects can create permanent weaknesses that persist even after the software is patched.

Incident response in cryptocurrency is unusually unforgiving

Traditional security incidents may allow organizations to reset passwords, revoke sessions, reverse fraudulent payments or restore affected systems from backup.

Cryptocurrency incidents offer far fewer recovery mechanisms. Once an attacker obtains the private key and broadcasts a valid transaction, there may be no central authority capable of reversing the transfer.

This makes early warning and decisive migration extremely important. Users who believe their seeds may have been generated by affected firmware should not wait for conclusive attribution of the reported theft before taking protective action.

At the same time, rushed migration creates its own risks. Attackers frequently exploit public security incidents by publishing fake firmware, fraudulent migration tools and phishing instructions designed to steal recovery phrases.

Users should obtain firmware only from official sources, verify signatures where supported and never enter their recovery words into a website, desktop utility or support form.

Migration should be performed directly through trusted wallet hardware and verified software. The destination address should be checked on the hardware-wallet screen rather than trusted solely from a potentially compromised computer.

For substantial holdings, users may consider moving funds in stages and confirming each transaction before proceeding.

Never disclose the recovery phrase while seeking help

A predictable-seed vulnerability naturally creates anxiety among affected users, which gives criminals an opportunity to impersonate the manufacturer, researchers or support personnel.

No legitimate support representative needs the user’s recovery words to determine whether a firmware version was affected. The seed phrase, private key and passphrase should never be provided through email, chat, messaging applications or web forms.

Users should also be suspicious of unsolicited messages claiming that their wallet has been identified as vulnerable or offering automated recovery services.

The appropriate remediation is to update through official channels, generate a new seed locally on corrected hardware and transfer funds to addresses verified on the device.

Anyone requesting the old seed to “check” whether it is exposed is not performing customer support. They are asking for the keys to the vault while wearing a poorly printed customer-service badge.

Enterprises need stronger cryptocurrency custody controls

Organizations holding substantial cryptocurrency should not depend on a single device, administrator or wallet-generation process.

Institutional custody should use documented ceremonies for key generation, with multiple witnesses, verified firmware, controlled physical environments and independent entropy sources.

The devices used for multisignature arrangements should ideally include different manufacturers or independently implemented signing systems. This reduces the likelihood that one firmware defect compromises the entire signing quorum.

Organizations should record the exact device model, firmware version, generation method, entropy source, wallet fingerprint and custody chain associated with each key.

Regular recovery exercises should confirm that backups are valid without exposing them unnecessarily. Transaction policies should require multiple approvals and independent verification of destination addresses.

High-value wallets should also support rapid migration when a component is found vulnerable. An emergency response plan should define who can authorise migration, which backup devices will be used and how destination keys will be verified.

Without such preparation, an organization may discover that its supposedly secure cold-storage system cannot be changed quickly without assembling several executives, locating a safe-deposit key and finding the one employee who remembers why a particular microSD card was labelled “final-final-2.”

The broader cybersecurity lesson

The COLDCARD vulnerability demonstrates that secure random-number generation is not merely one cryptographic feature among many. It is the foundation on which private-key security depends.

Encryption algorithms, secure elements, air gaps and tamper-resistant hardware cannot compensate for predictable key generation. If attackers can reproduce the initial secret, every protective layer built around that secret becomes less relevant.

The incident also highlights the danger of integration errors in security-critical software. The hardware random-number generator itself may function correctly, the secure element may operate as designed and the wallet may verify signed firmware properly, yet a small configuration mismatch can route key generation around those protections.

Security must therefore be validated as a complete system rather than inferred from the presence of individual secure components.

For COLDCARD users, the immediate priority is to determine which firmware generated their wallet seed. Users whose seeds were created through affected releases without sufficient independent dice entropy should install the corrected firmware, generate a completely new seed and migrate funds carefully.

For wallet manufacturers, the lesson is that entropy paths require explicit validation, fail-closed behaviour, production-build testing and independent review. Cryptographic randomness should never be selected through ambiguous preprocessor logic or silently replaced by a deterministic fallback.

For the wider cybersecurity community, the incident is another reminder that trust must be continuously verified. A device designed exclusively for protecting private keys can still contain a weakness in the very process that creates them.

Hardware wallets remain an important security tool, but the word “hardware” is not a magic spell that makes software defects disappear. Secure custody depends on the entire chain, from the first unpredictable bit used to generate the seed to the final transaction approved by the owner.

An attacker drained 1,196 Bitcoin addresses in 41 minutes on July 30, taking 1,082.65 BTC worth about $70.2 million at the time. Galaxy Research mapped the sweep and tied it to a firmware flaw in Coldcard, the Bitcoin-only hardware wallet made by Canadian firm Coinkite. A March 2021 firmware integration error routed seed generation to a deterministic software pseudorandom number generator (PRNG

Source: Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes via The Hacker News — published 01 Aug 2026.