COLDCARD Predictable RNG: From Seed Recovery to About $8.86M Bitcoin Theft

COLDCARD Predictable RNG: From Seed Recovery to About $8.86M Bitcoin Theft

1. Basic Information

• Article Title: COLDCARD wallet RNG flaw likely linked to $88 million Bitcoin theft
• Source: BleepingComputer
• Publication Date: August 2, 2026
• Severity: Urgent
• Original Link: https://www.bleepingcomputer.com/news/security/coldcard-wallet-rng-flaw-likely-linked-to-88-million-bitcoin-theft/
• Related Sources:
  • Block Engineering “Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware”: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
  • Coinkite “Coldcard Security Advisory”: https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
• Related Malware / Threat Actors: Unknown. The attack may not require malware or phishing.
• CVE: None assigned at the time of publication
• Related Products: COLDCARD Mk2/Mk3 4.0.0–4.1.9, Mk4/Mk5 below fixed versions, Q below fixed versions. TAPSIGNER, OPENDIME, and SATSCARD are considered unaffected.
• Relation to Real Exploitation: Strongly suspected to be linked to the theft of a total of 1,367 BTC (approx. $88.6 million at the time of reporting) observed between July 30 and August 1, 2026. However, cryptographic or investigative confirmation of the attacker exploiting the vulnerability has not been officially established.

2. Executive Summary

Due to a conditional branching error in the COLDCARD firmware, wallet seed randomness became deterministic or fell into a narrow candidate space. This may have allowed attackers to use public Bitcoin addresses as a verification oracle to offline-reproduce seeds and private keys, moving funds without ever breaking into the physical devices.

3. Attack Flow

Chain A: Fund Theft from Existing Wallets (Chain Suspected to be Linked to Real Damage)

1. A user generates a new seed, paper wallet, or related key material on an affected firmware version.
2. The firmware uses the MicroPython Yasmarang fallback instead of the hardware RNG where it should use it.
3. On Mk2/Mk3, no cryptographic entropy is added, resulting in a deterministic output dependent on UID, SysTick, RTC values, and call history. On Mk4/Q/Mk5, even when values derived from the secure element are hashed, only 4 bytes remain for the reseed, and Block evaluated the secure stream under fixed conditions to be a maximum of 2^32.
4. The attacker estimates the target model, firmware, device ID, time, and boot condition candidates, and offline-enumerates RNG states and seed candidates.
5. The attacker derives Bitcoin addresses/xpubs from each candidate and checks if they match target addresses on the public blockchain. Address matching serves as a verification oracle for seed candidates.
6. The attacker derives private keys from the matched seed and signs sweep transactions in their own environment.
7. The attacker broadcasts transactions to the Bitcoin network and moves victim UTXOs to the attacker’s address.
8. The observed theft waves showed automated traits: a fixed fee of 30 sat/vB, no change output, rapid batch processing, and prioritization of high-value wallets.

Chain B: Other Impacted Features (Capabilities Confirmed, Abuse in Current Theft Unverified)

1. The same randomness path generates paper-wallet keys, Seed XOR masks, some ECDH keys for cloning/USB/Key Teleport/Web2FA, Secure Notes passwords, and HSM local-code material.
2. The attacker obtains verification materials such as public keys, addresses, and captured sessions.
3. The attacker enumerates the limited candidate space and reproduces the corresponding secret values.
4. Inference: If protocol conditions for each function are met, this could lead to session/backup decryption or local-code estimation. Direct links to wallet signing keys vary by function.

4. Attacker Position and Execution Location

• Key searching can be executed offline on CPU/GPU environments controlled by the attacker. Network connection to the victim device or malware execution is not required.
• The public blockchain, known addresses/xpubs, device models, firmware, and generation times may be used for search and candidate verification.
• Signing is also performed in the attacker’s environment, and only completed transactions are broadcast to the Bitcoin network.
• The primary investigative characteristic is that funds can be moved without any traces of intrusion on the victim device, PC, or IdP.

5. Victim and Administrator Perspective

Victims

• Balances are moved even though the hardware wallet was never connected or authorized.
• There are no signs that seeds, PINs, or backups on the device were physically stolen.
• There are likely no common precursors such as suspicious emails, browser logins, malware alerts, or MFA prompts.
• Even if the firmware is updated now, seeds generated in the past on affected versions remain dangerous.

Administrators / SOC

• There are almost no traces in EDR or IdPs; blockchain transactions and seed generation provenance serve as the main evidence.
• Common traits include the same fee rate for multiple wallets, no change outputs, continuous rapid sweeps, and common destination clusters.
• In organization-managed wallets, transfers appear as valid cryptographic signatures without any signature approval records.

6. Success and Failure Conditions

Success Conditions

• The seed or related key material was generated on an affected firmware version.
• Independent private dice rolls were fewer than 50, or sufficient external entropy was not added.
• There is no strong, unique BIP-39 passphrase, or the attacker can estimate it.
• Public information is available to verify candidates, such as target addresses/xpubs.
• The attacker can narrow down the model, UID, RTC, generation time, and boot/call history to a realistic range.
• Funds remain at addresses under the old seed.

Failure Conditions

• Funds have already been migrated to a new seed generated in an unaffected environment.
• At least 50 fair, independent, and private dice rolls were added during seed generation.
• A sufficiently strong and unique BIP-39 passphrase is kept secret (though the vendor still recommends migrating to a final new seed).
• The multisig quorum includes a sufficient number of unaffected devices and independent entropy keys.
• The attacker cannot identify the address/xpub or generation conditions to verify candidates, making the search cost higher than the asset value.
• The victim sweeps funds to a safe wallet before the attacker does.

7. What Happens Upon Success

• The attacker can reproduce private keys without reading seed phrases directly from the device or backups.
• Because signatures are made by valid private keys, the blockchain network cannot reject unauthorized transfers.
• Unused addresses, future deposits, and related accounts under the same seed remain continuously at risk.
• In the recent observation, 1,367 BTC were reported moved across 4,585 addresses in 3 waves.
• Related functions such as paper wallets may also allow key material recovery using public information as an oracle.

8. Observable Logs

Email

• No email specific to the attack chain is required. Vendor advisories and custodian notifications are post-incident information.

Proxy / SWG / DNS

• Communication from the victim device to the attacker’s C2 is not expected; absence of evidence does not indicate safety.
• Only normal communication with wallet software or Bitcoin nodes may remain.

Endpoint / EDR

• Because the attack does not involve malware or process injection, normal EDR detection is not expected.
• Preserve firmware images/versions, device serials/models, seed generation dates, wallet application logs, and hardware-wallet connection history.
• Inference: In organizational operations, a mismatch between seed ceremony records and signing workstation logs serves as important negative evidence.

Identity / IdP

• IdP authentication is not required for the attack to succeed. Check login, API key, and withdrawal logs only if funds entered or exited exchange/custody accounts.

SaaS / Cloud

• Check approval records, API calls, and webhooks in custody services, treasury workflows, and transaction approval SaaS.
• Even if on-chain signatures are valid, the lack of internal approval records acts as a strong incident signal.

Network

• Transaction timestamps on Bitcoin nodes/mempools, input UTXOs, a fixed fee of 30 sat/vB, no change outputs, common destinations, and rapid continuous sweeps.
• The fact that a transaction was not broadcast from the organization’s own node is auxiliary evidence, but not conclusive on its own due to possible legitimate operations via external nodes.

9. Attack Success Assessment

• Contact Only: Simply owning the applicable model and firmware. Requires investigation if the seed generation version is unknown.
• User Action: Confirmed from records that the seed/key material was generated on an affected version. This is an exposure condition, not successful compromise.
• Initial Execution: Code execution on the victim environment is not required in this attack. Offline candidate searches are difficult to observe from the victim side.
• Malware or Successful Authentication: N/A. Matching private key candidates can only be confirmed on the attacker’s side.
• Data Theft / Session Compromise: Strongly suspect seed/private-key compromise if unauthorized transactions have valid signatures, normal seed exfiltration paths are ruled out, and generation on affected firmware is confirmed.
• Subsequent Compromise Confirmation: Confirm continuous sweeps of addresses under the same seed, deposits to attacker clusters, lack of internal approvals, and matches with known wave characteristics using multiple pieces of evidence.

10. Investigation Playbook

Trigger

• Unauthorized outbound transactions from COLDCARD-derived wallets
• Discovery of holding seeds generated on affected firmware
• Matching known sweep clusters or common transaction patterns

Initial Verification

1. Prioritize migrating unspent UTXOs to a new seed generated in an unaffected environment to stop fund movement.
2. Verify device models, seed generation versions (rather than current versions), generation timestamps, dice rolls, passphrases, and multisig configurations.
3. Preserve transaction IDs, raw transactions, mempool/confirmation times, inputs/outputs, fees, change, and destination clusters.
4. Check whether authorized signers, approval systems, or wallet operators created the transaction.

Devices

• Preserve firmware files/hashes, update history, wallet applications, hardware connection history, and backup creation dates.
• Do not copy seed phrases or passphrases into tickets, chats, or SIEMs.
• Updating the device does not repair old seeds, so do not close incidents based on updates alone.

Authentication and Cloud

• Check exchange/custodian logins, API keys, withdrawal whitelists, MFA, and support resets to rule out account takeover via other paths.
• Cross-reference treasury approvals, signing services, and HSM/KMS audits.

Subsequent Operations

• Inventory all accounts/addresses derived from the same seed, watch-only wallets, and unused change addresses.
• Track subsequent movements from attacker addresses to mixers, exchanges, and bridges, and contact exchanges and law enforcement as needed.
• Confirm whether paper wallets, Seed XOR, cloning/USB, Web2FA, Secure Notes, or HSM functions were used.

Containment

• After verifying backups, update to the fixed firmware version, and verify the new seed and receiving address on the device.
• After a small test transaction, move all funds under the old seed to the new wallet.
• For multisig, verify the generation provenance of each signer, and rotate keys if a quorum can be formed using only affected devices.
• Even when passphrases are used, migration remains the permanent solution; do not reuse old seeds.

Assessment Categories

• Device Only / Seed Provenance Unknown
• Vulnerable Seed Confirmed
• Exposure Mitigated by Independent Entropy
• Unauthorized Spend Suspected
• Private-Key Compromise Highly Likely
• On-chain Theft Confirmed

11. Defense and Detection Ideas

Single Events

• Unauthorized outbound transactions from target wallets
• Records of seed generation on affected versions
• Valid signed transactions without approval records

Time-Series Correlation

Seed generation on affected firmware
→ Long-term normal use
→ Simultaneous sweeps with identical fee rates and no change outputs
→ Aggregation into a common attacker cluster
→ Subsequent movement to mixers/exchanges, etc.

Enter fullscreen mode Exit fullscreen mode

Hunting Perspectives

• Search for organizational address groups within known attack windows, 30 sat/vB fees, no change outputs, and destination clusters.
• Extract COLDCARD wallets for which the seed generation firmware cannot be tracked.
• Compare patterns where higher-value wallets moved first against organizational balances and address reuse.
• Confirm whether multisig signers are concentrated in the same vendor, firmware, or ceremony.

Log Gaps

• Lack of records for seed ceremonies, device models/serials, firmware at generation, dice entropy, and passphrase presence
• Insufficient retention of raw transactions, approvals, and signing device logs
• Insufficient self-custody address inventories and blockchain monitoring

Priority Countermeasures

1. Do not stop at updating current firmware; migrate funds from seeds generated on affected versions.
2. For high-value wallets, adopt independent entropy, multisig across heterogeneous implementations, and documented key ceremonies.
3. Subject self-custody addresses to 24/7 blockchain monitoring and out-of-band approval cross-referencing.
4. Conduct security reviews and testing on entropy sources, compile-time flags, fallbacks, and reseed ranges during firmware releases.

12. Facts / Inference / Hypothesis

Facts

• libngu checks whether MICROPY_HW_ENABLE_RNG is defined using #ifndef, and selected the MicroPython fallback even in production builds where the value is 0.
• Block analyzed that on Mk2/Mk3, no cryptographic entropy was added to the fallback, and on Mk4/Q/Mk5, only 4 bytes of secure-element output remained for reseeding.
• SHA-256/SHA256d/BIP-39 processing does not increase the search space of the input seed family.
• Public addresses/xpubs act as oracles to verify candidate seeds.
• Updating to fixed firmware does not make seeds generated on older versions safe.
• Reports stated that 1,367 BTC across 4,585 addresses were moved in 3 waves between July 30 and August 1.
• The first wave processed 1,196 addresses in approximately 41 minutes using the same 30 sat/vB fee and no change outputs.
• Block stated that no complete end-to-end empirical exploitation test was performed.

Inference

• Fast, homogeneous, and high-value-prioritized sweeps right before disclosure align with attack tools that automatically recovered keys from vulnerable RNGs.
• However, transaction patterns and time series alone cannot uniquely prove the exploitation of the COLDCARD flaw.
• For organizational SOCs, correlating asset provenance, approval logs, and blockchain analysis is more effective than endpoint telemetry.
• Coinkite’s evaluation of “approx. 72 bits of entropy” and Block’s evaluation of “up to 2^32 secure streams” under fixed conditions may have different premises, so it is better not to lock them down as a single security-bit value.

Hypotheses

• Attackers may have pre-collected device models, generation times, UIDs, or usage patterns to build candidate databases prioritizing high-balance addresses.
• Address reuse, public xpubs, and leaked wallet telemetry may have greatly assisted in narrowing down candidates.
• Periods of inactivity for stolen BTC may be used to monitor additional sweeps, evade tracking, and adjust cash-out routes.

13. MITRE ATT&CK Mapping

Enterprise ATT&CK does not directly represent offline seed reproduction for crypto wallets, so the mapping below is limited.

• T1657 – Financial Theft (High Confidence): Cryptocurrency theft via unauthorized signed transactions.
• T1110 – Brute Force (Low Confidence / Conceptual Mapping): Offline enumeration of RNG states/seed candidates, though different from standard password authentication brute force.
• T1552 – Unsecured Credentials (Low Confidence): Recovering secret values equivalent to private keys, but not a technique that directly reads stored credentials.
• T1588.006 – Obtain Capabilities: Vulnerabilities (Medium Confidence / Inference): When an attacker turns a firmware flaw into an operational key recovery capability.

14. Unknowns and Additional Investigations

• Forensic evidence directly connecting the observed 1,367 BTC theft to the COLDCARD flaw
• How attackers acquired or estimated UIDs, generation times, and call histories
• Effective search spaces and measured costs by model, version, and generation condition
• Premise differences between Coinkite’s ~72-bit evaluation and Block’s max 2^32 secure-stream evaluation
• Seed generation versions, dice rolls, passphrases, and multisig configurations of each victim wallet
• Final cash-out/laundering destinations of stolen BTC and attacker attribution
• Abuse in non-wallet functions such as Web2FA, cloning, Secure Notes, and HSM

15. Impact on Global SOCs and Enterprises

Organizations globally utilize COLDCARDs not only for personal holdings but also across crypto asset exchanges, Web3 businesses, treasury assets, executive/founder assets, and custody services. What needs to be verified is not the “current firmware,” but “the firmware and entropy at the time the seed currently protecting funds was generated.” Self-custody wallets are easily missed in IT asset inventories, and because they cannot be detected by EDR/IdP-centric SOCs, organizations must integrate wallet inventories, key ceremonies, approvals, and blockchain monitoring.

For high-value assets, do not rely on a single device vendor; instead, adopt independent entropy, multisig across heterogeneous implementations, and auditable records of seed ceremonies. During migrations, anticipate panicked actions and fake support scams. Make official firmware hash verifications, address checks on device screens, small test transactions, and dual approvals mandatory.

16. Summaries by Target Audience

For SOCs

• Assuming no traces exist in EDRs, correlate unauthorized transactions, missing approvals, seed generation versions, and on-chain clusters.
• Differentiate between simply holding vulnerable devices, confirming vulnerable seeds, and actual unauthorized signatures and fund thefts.
• A 30 sat/vB fee, no change outputs, and rapid sweeps are auxiliary indicators and should not be used alone to determine root causes.

For Administrators

• Check backups, update to official fixed versions, generate new seeds, and migrate all funds from old seeds.
• Inventory not only current firmware but also seed provenance, dice entropy, passphrases, and multisig signer configurations.
• Even if a strong passphrase is used, do not rely on continued use of old seeds as a permanent solution.

For Users

• Updating firmware alone will not fix old seeds. Follow official advisories to move to new seeds and wallets.
• Do not hand seed phrases or passphrases to the web, chat, or support staff. During migration, verify addresses on device screens and perform a small test first.