Un fallo en el firmware de Coldcard vinculado al robo de más de 1.000 bitcoin

El 30 de julio de 2026, el fabricante de hardware wallets Coinkite confirmó que un fallo de firmware debilitó la forma en que varios modelos Coldcard generan las semillas de los monederos. Ese mismo día, unos 594,48 bitcoin salieron de cerca de 500 monederos en una ventana de pocos bloques. Desde entonces, los analistas on-chain han vinculado un total de unos 1.082 bitcoin, por valor de unos 70 millones de dólares, a la misma firma.

La fuente primaria de este artículo es el propio aviso de seguridad de Coinkite, publicado el 30 de julio y actualizado el 1 de agosto.

Qué ocurrió

Según el análisis on-chain compartido primero por el consejero delegado de AnchorWatch, Rob Hamilton, 1.324 salidas no gastadas se consolidaron en 500 transacciones dentro de una ventana de tres bloques, con un total de 594,48 bitcoin. Después, unos 562 bitcoin se movieron de nuevo a una única dirección nueva, que desde entonces no ha vuelto a mover los fondos.

Las salidas vaciadas databan de 2021 a 2026. Todas las direcciones afectadas eran de firma única y ninguna usaba Taproot. Clay Garrett, responsable de ingeniería del monedero Bitkey de Block, identificó más tarde 695 transacciones anteriores con la misma huella, que movían otros 488,11 bitcoin. Si pertenecen al mismo operador, el total combinado alcanza unos 1.082,59 bitcoin.

Chainalysis informó de que el atacante vació primero los monederos de mayor valor, incluido uno que contenía unos 1,8 millones de dólares, y que unos 30 millones de dólares salieron en los primeros diez minutos antes de que se vaciaran los monederos restantes.

Qué confirmó Coinkite

Coinkite atribuyó la causa a una generación de semillas que se apoyaba en un generador de números aleatorios por software en lugar de en la fuente de hardware prevista. La empresa estima el espacio de búsqueda efectivo en unos 40 bits en la Mk2 y la Mk3, y en unos 72 bits en la Mk4, la Mk5 y la Q, frente al objetivo de 128 bits para una semilla de doce palabras.

El aviso identifica así la generación de semillas afectada.

Modelo	Generación de semilla afectada
Coldcard Mk2 y Mk3	Firmware de 4.0.1 a 4.1.9
Coldcard Mk4 y Mk5	Antes del firmware estándar 5.6.0 (Edge antes de 6.6.0X)
Coldcard Q	Antes del firmware estándar 1.5.0Q (Edge antes de 6.6.0QX)

Coinkite afirma que Tapsigner, Opendime y Satscard no están afectados, porque usan bases de código distintas. La empresa también señala que una semilla creada con al menos cincuenta tiradas de dados independientes y privadas no se considera en riesgo solo por este problema.

Coinkite ha publicado firmware corregido para todos los modelos afectados, incluida la versión 4.2.0 para la Mk2 y la Mk3. Un registro de cambios anterior había dicho que la empresa no planeaba actualizar la Mk3 en aquel momento, una posición que después ha revertido.

Qué recomienda Coinkite

Coinkite afirma que una actualización de firmware no repara una semilla ya generada por firmware afectado, y que reimportar la misma semilla en un dispositivo nuevo tampoco ayuda, porque la debilidad reside en la propia semilla. La empresa recomienda a los usuarios afectados actualizar el firmware, generar una semilla completamente nueva, verificar la copia de seguridad y una dirección de recepción, enviar una pequeña transacción de prueba y después trasladar los fondos restantes.

Un rastro hasta un proveedor de datos

El equipo de seguridad de Block informó de que el operador usó una cuenta de pago en un conocido proveedor de servicios blockchain para consultar las direcciones de origen y llevar a cabo pasos relacionados durante los barridos. Según Garrett, los registros internos del proveedor coincidían con el número, el momento y el orden de las consultas visibles on-chain. Block afirma que no encontró pruebas de que el proveedor ayudara conscientemente al robo, y que ha remitido sus hallazgos a las autoridades.

Coinkite añadió que asume que alguien usó un modelo de IA para revisar su firmware, que es público, y encontró el fallo. La empresa dijo que había pasado su propio código por uno de los mejores modelos de IA disponibles unas semanas antes, y que esa revisión no detectó el error.

El análisis complementario de CanoeBit explica cómo llegó el fallo al firmware, por qué una semilla débil no puede repararse y qué significa el caso para la narrativa más amplia de que "air-gapped equivale a seguro".