COLDCARD Security Advisory A seed-generation defect affected releases beginning with firmware 4.0.1. Fixed firmware is available. Existing affected seeds still require migration. Check status
Written by Coinkite Team

COLDCARD SECURITY

Check the code, firmware, and device.

COLDCARD publishes the material needed to inspect important software and device-security claims. Verification does not mean assuming that open source, an air gap, or a green light solves every threat. It means checking the specific control before you depend on it.

Open the firmware source Report a security issue

Current firmware status

Fixed firmware is available for every supported COLDCARD model and release track. The minimum fixed releases are Mk2/Mk3 4.2.0, Mk4/Mk5 5.6.0, Q 1.5.0Q, Mk4/Mk5 Edge 6.6.0X, and Q Edge 6.6.0QX.

Updating corrects future seed generation but does not repair an existing affected seed. Follow the advisory's migration guidance unless its independent-dice exception applies.

Check the current status and evidence Read the security advisory

The fixed source is preserved in the release tags. Git ancestry confirms that the mainline remediation is included in the Mk4/Mk5 5.6.0 and Q 1.5.0Q tags. The Mk2/Mk3 remediation is included in 4.2.0. The Edge remediation is included in 6.6.0X and 6.6.0QX.

Start with four checks

Read the firmware source

The Q and Mk-series firmware source is published for review. Inspect the implementation, release tags, build instructions, and changes instead of relying only on a product description.

Browse the firmware repository

Verify a firmware download

The Downloads page publishes current firmware files. The upgrade guide explains how to compare the SHA-256 hash and verify the signed signatures.txt file before loading firmware.

Open firmware verification

Check the device before entering a PIN

At boot, the secure element checks the flash contents against its recorded checksum before lighting GENUINE (green) or CAUTION (red). If the CAUTION light remains red, do not enter your PIN. Stop and investigate.

Review the hardware checks

Disclose a vulnerability privately

Coinkite accepts reports at security@coinkite.com, coordinates PGP-encrypted follow-up, and may pay a Bitcoin bounty for a qualifying report with a working proof of concept.

Read the disclosure process


Independent review of the July 2026 RNG remediation

Independent technical reviewers have examined specific parts of the firmware remediation.

A real-device test confirmed the corrected hardware path. Shiny instrumented a Mk4 running firmware 5.6.0 and observed eight STM32 hardware RNG reads for the 32-byte seed request. This confirms that the fixed seed-generation path reaches the hardware TRNG. Read the test.

A source review covered every fixed release line. Mike Rahel reviewed Mk2/Mk3 4.2.0, Mk4/Mk5 5.6.0, Q 1.5.0Q, and Edge 6.6.0X/6.6.0QX. The review confirmed the hardware rng_get() implementation, removal of the software fallback, and the build-time check that rejects the wrong implementation. Read the review.

A separate source review checked the hotfix mechanics. Mars confirmed that the hotfix removes the MicroPython fallback, exports the hardware rng_get() implementation, and stops builds that link the wrong implementation. Read the review.

A reproducible build connected released source to the published Mk firmware. PortlandHODL rebuilt firmware 5.6.0 and matched every code and data byte in the published signed file, excluding its signature and timestamp header. The same report traced the independent-dice path and recomputed its result outside the firmware. This confirms source-to-binary identity and the dice workflow; it is not a hardware-RNG test. Read the report.

Independent technical articles add context without replacing those checks. Wizardsardine's incident analysis identifies the fixed release boundaries and distinguishes future seed generation from migration of an existing seed. Block's root-cause analysis explains the original failure, but it is not a review of the released fix.

These findings validate specific remediation mechanisms. They are not a complete audit of every released firmware binary and do not guarantee that COLDCARD is free of defects. Updating corrects future seed generation but does not repair an existing affected seed. Follow the security advisory unless its independent-dice exception applies.


What each check proves

Published source makes review possible. It lets researchers inspect the firmware and lets advanced users reproduce a release build. Public code does not prove that the code has no bugs or that every hardware claim is correct.

A reproducible build compares source with a binary. A matching result supports the claim that the released firmware corresponds to the tagged source and documented toolchain. It does not prove that the source is free of vulnerabilities.

A signature identifies approved firmware. COLDCARD checks that firmware was signed by an approved Coinkite key. A valid signature does not make every signed release safe forever, so check the current version and release notes before upgrading.

The GENUINE/CAUTION status is a boot-time flash check. It helps detect an unexpected change before PIN entry. It does not replace inspection of the numbered tamper-evident bag, the clear case, your anti-phishing words, or the transaction details on screen.

Before this wallet holds more than spending money

Security is not one chip or one badge. Before placing a meaningful amount of bitcoin in a new wallet:

Check the current security status and install current firmware before generating the savings seed. Keep spending and savings on separate seeds. A seed generated by current fixed firmware is sufficient; private dice rolls are optional if you want additional independence from any one random-number generator. Fifty fair rolls add at least 128 bits of entropy; 99 add about 256 bits. Never save or photograph the roll sequence.

A strong, unique BIP-39 passphrase can protect a stolen seed backup, but it creates another permanent-loss risk. Back it up exactly, keep it separate from the seed when theft resistance is the goal, record the expected wallet fingerprint, and test recovery.

  1. Buy from Coinkite or an authorized reseller and inspect the numbered tamper-evident bag.
  2. Confirm the bag numbers, tear-off tab, and bag number shown by the device agree.
  3. Wait for the GENUINE status before entering the PIN.
  4. Record and verify the anti-phishing words produced by the PIN prefix.
  5. Back up the seed on durable media, pass the on-device quiz, and keep redundant recovery material offline in appropriate separate locations.
  6. Export a watch-only wallet and verify a receive address on the COLDCARD screen.
  7. Receive a small test amount, sign one Partially Signed Bitcoin Transaction (PSBT), and verify destination, amount, fee, and change on the device.
  8. Test the documented recovery path before relying on the wallet for a larger balance. Single-sig plus a recoverable passphrase is valid for many people; add multisig only when the fault-tolerance or continuity benefit justifies its operational load.

Start with the first-session checklist

Know the limits

QR and MicroSD signing remove a live data connection between the signer and an internet-connected coordinator. The COLDCARD still parses transaction data carried across that gap. Review the payment details on its screen before signing.

Dual secure elements reduce dependence on a single chip vendor. They do not protect a seed phrase that was photographed, typed into a phone, or stored with its passphrase.

Bitcoin-only firmware reduces protocol scope. It does not mean the remaining code cannot contain a defect.

A clear case and numbered tamper-evident bag make physical inspection easier. They do not replace buying from a known source or checking the device at first use.


Found a security issue?

Keep the report private, preserve user data, and send a reproducible proof of concept to Coinkite's security contact.

Report a COLDCARD security issue

Methodology and primary evidence

Reviewed on August 8, 2026.

Method. We checked each claim against the current firmware repository, official release files, and the device documentation linked below. We separated controls that a user can observe on a device from design claims that depend on published documentation or source review. Firmware-dependent behavior can change, so release notes and the installed version remain part of the check.

Limits. Coinkite publishes these primary sources. Publication makes the claims inspectable; it is not an independent audit and does not prove the absence of vulnerabilities. Reproducible builds address whether a release binary corresponds to source, not whether that source is safe.

Claim-to-evidence map: