El 30 de julio de 2026, entre la 1:10 y la 1:51 de la madrugada UTC, alguien vació 1.082,65 bitcoins de 1.196 carteras distintas. Cuarenta y un minutos. Unos 70 millones de dólares al cambio de aquel día.
No hubo phishing, ni malware, ni descuidos de los usuarios. Las víctimas hacían justo lo que se supone que hay que hacer: guardar sus bitcoins en una cartera física, un aparato dedicado y desconectado de internet. Uno de los afectados contó que el suyo llevaba años metido en la caja fuerte de un banco.
El problema estaba dentro del aparato desde marzo de 2021, y cabía en una línea de código.
Las Coldcard de la empresa canadiense Coinkite llevaban cinco años generando las frases semilla —las doce o veinticuatro palabras de las que se derivan todas tus claves— con un generador de números aleatorios de juguete en lugar de con el chip de hardware que tenían para eso. Y un número aleatorio que no es aleatorio de verdad se puede adivinar.
A fecha de hoy el robo se ha extendido a tres oleadas confirmadas y varios episodios menores: cerca de 1.600 bitcoins de unas 7.300 direcciones, y se investiga una cuarta oleada que llevaría el total por encima de los 2.000 BTC, unos 130 millones de dólares.
Vamos a ver exactamente qué falló, por qué es tan grave, y qué tiene que hacer alguien con una de estas carteras.
El error: comprobar que una opción existe en vez de si está activada
La causa raíz, documentada por los equipos de ingeniería y seguridad de Block junto a investigadores anónimos, es de las que dan escalofríos por lo pequeña que es.
La Coldcard lleva un chip STM32 con generador de números aleatorios por hardware, que es lo que debe usarse para crear una semilla. Pero el firmware está construido sobre MicroPython, y MicroPython trae su propio generador por software como recurso de emergencia para placas que no tienen hardware: un algoritmo llamado Yasmarang, pensado para simulaciones y videojuegos, no para custodiar dinero.
Para decidir cuál usar, la biblioteca de criptografía de Coinkite comprobaba una opción de compilación así:
#ifndef MICROPY_HW_ENABLE_RNG
Ahí está todo el desastre. #ifndef pregunta si la opción existe, no si vale 1 o 0. Y la configuración de la placa de la Coldcard la define… con valor cero, precisamente porque el hardware se gestiona aparte, con código propio.
Resultado: la opción existía, la comprobación pasó, el firmware compiló sin un solo aviso y se quedó enganchado al generador de emergencia por software. Durante cinco años.
Qué tiene de malo Yasmarang aquí
Que se inicializa con tres cosas que de aleatorias no tienen nada:
- El número de serie del chip, que es fijo de por vida y se puede leer de memoria.
- El contador SysTick, que se reinicia cada milisegundo y solo toma unos 80.000 valores distintos en los modelos antiguos.
- Dos registros del reloj de tiempo real, que además están correlacionados entre sí y con el anterior.
Hay un detalle que remata la faena. El código intentaba reforzarlo haciendo un XOR con un segundo generador Yasmarang inicializado con constantes públicas. Como resumió Block en su análisis: “el XOR no crea entropía; si las dos entradas son reproducibles, su XOR es reproducible”.
Qué es la entropía de una semilla, en corto. Una frase semilla de 12 palabras debería tener 128 bits de entropía: 2¹²⁸ combinaciones posibles, un número tan absurdamente grande que probarlas todas es imposible con cualquier ordenador que exista o vaya a existir.
Con este fallo, los Mk2 y Mk3 bajaron a un techo de unos 40 bits, y los Mk4, Mk5 y Q a unos 72. Y esos son los techos optimistas: en el peor caso, conocido el número de serie del aparato y el historial de llamadas, la secuencia es completamente determinista.
Pasar de 2¹²⁸ a 2⁴⁰ no es “un poco menos seguro”. Es la diferencia entre imposible y una tarde de cálculo.
El parche que tampoco parcheaba
En 2022, para los Mk4 y posteriores, Coinkite añadió un resembrado desde el elemento seguro del aparato. Sobre el papel, arreglado. En la práctica, dos fallos encadenados:
- Se calcula un hash SHA-256 doble de 32 bytes… y solo llegan cuatro bytes a la función de resembrado.
- Esa función se limita a sobrescribir una única variable del estado interno del generador, sin reiniciar el resto.
Traducido: como mucho 2³² secuencias distintas, unos 4.300 millones. Suena a mucho y no lo es: es cuestión de horas para cualquiera con una tarjeta gráfica decente.
Cómo se convierte un fallo de entropía en un robo masivo
Lo que hace que este fallo sea tan explotable es que el atacante no necesita tocar el aparato. Ni acercarse. Ni saber quién eres.
El procedimiento es de una eficacia brutal:
- Genera candidatos. Recrea las secuencias posibles del generador defectuoso, recorriendo el espacio reducido de valores iniciales.
- Deriva las direcciones. De cada semilla candidata salen, con las reglas estándar de Bitcoin, todas sus direcciones públicas.
- Pregunta a la cadena de bloques. Aquí está la clave: la blockchain es pública. No hace falta atacar a nadie para comprobar si has acertado — basta con mirar si esa dirección existe y tiene saldo.
- Se lo lleva. Si hay coincidencia, ya tienes la clave privada.
Ese tercer paso es lo que convierte un problema teórico en un robo industrializado: el atacante puede barrer millones de candidatos contra el registro público sin dejar rastro y sin alertar a nadie, y solo aparece cuando ya está firmando las transferencias.
Las oleadas
- 30 de julio: 1.082,65 BTC de 1.196 direcciones, en 41 minutos. Unas 30 horas antes de que Coinkite publicara su primer aviso.
- 31 de julio: 76,16 BTC de 1.478 direcciones.
- 1 de agosto: 207,73 BTC de 1.912 direcciones.
El goteo posterior apunta a que, una vez conocido el fallo, otros se pusieron a buscar carteras vulnerables por su cuenta. Es el efecto secundario inevitable de una divulgación con el problema ya en explotación activa.
Las carteras de papel son el caso peor. En una cartera normal, la salida del generador pasa por los estándares BIP-39 y BIP-32 antes de convertirse en claves. En una cartera de papel, la salida del generador se usa directamente como clave privada, sin pasos intermedios.
Eso significa que un atacante puede generar claves candidatas, derivar su dirección y compararla contra cualquier dirección de cartera de papel conocida. Sin intermediarios y sin margen.
Quién lo encontró
Conviene separar los dos papeles, porque se están mezclando en muchas coberturas. El análisis técnico del fallo lo publicaron los equipos de Bitcoin Engineering y Security de Block con investigadores anónimos. El rastreo de los movimientos en cadena que permitió identificar el patrón del robo salió de Galaxy Research.
Y hay un detalle que ha inquietado al sector: Coinkite ha reconocido que es probable que se usaran herramientas de inteligencia artificial para dar con el fallo. Un error de este tipo —una macro mal comprobada, enterrada en la configuración de una placa— es exactamente la clase de cosa que una auditoría humana lleva años pasando por alto y que un análisis automatizado a gran escala sí puede sacar a flote.
La pregunta incómoda que deja es evidente: cuántos fallos parecidos siguen dormidos en el firmware de otros fabricantes, esperando a que alguien pase la misma herramienta.
Qué modelos están afectados y qué hay que hacer
Lo primero y más importante, porque mucha gente lo entiende al revés: actualizar el firmware NO arregla tu semilla.
El firmware nuevo genera bien las semillas nuevas. La que ya tienes se creó con el generador roto y sigue siendo igual de adivinable por mucho que actualices. Coinkite lo dice sin rodeos: hay que crear una semilla nueva y mover los fondos.
Y ojo con esto: la exposición depende de con qué firmware se generó el secreto, no de cuándo compraste el aparato ni de qué cartera uses ahora. Si exportaste esa semilla a otra cartera, la semilla sigue comprometida allí también.
| Modelo | Firmware afectado | Entropía real | Versión corregida |
| Mk1 | Ninguno | No afectado | — |
| Mk2 y Mk3 | Hasta la 3.2.2 | No afectado (usaba el hardware) | — |
| Mk2 y Mk3 | De la 4.0.0 a la 4.1.9 | ~40 bits (sin resembrado) | 4.2.0 |
| Mk4 y Mk5 | Desde la 5.0.0 | ~72 bits (resembrado de 32 bits) | 5.6.0 |
| Q | Toda la producción | ~72 bits (resembrado de 32 bits) | 1.5.0Q |
| Mk4 / Mk5 Edge | Versiones previas | ~72 bits | 6.6.0X |
| Q Edge | Versiones previas | ~72 bits | 6.6.0QX |
| Tapsigner / Opendime / Satscard | Ninguno | No afectado (otro código) | — |
El procedimiento, en orden
Coinkite marca una secuencia concreta y el orden importa:
- Actualiza a la versión corregida.
- Genera una semilla nueva en el firmware ya parcheado.
- Verifica la copia de seguridad de esa semilla nueva.
- Prueba con una cantidad pequeña antes de nada.
- Migra el resto de los fondos.
- Conserva la copia antigua hasta que la migración esté completa y confirmada.
Las dos excepciones
No todo el mundo está expuesto. Te salvas si se da alguna de estas dos condiciones:
- Añadiste al menos 50 tiradas de dado justas, independientes y privadas al generar la semilla. Coinkite considera que en ese caso la semilla no está en riesgo por este fallo, porque la entropía la pusiste tú y no el generador roto.
- Tienes una frase de contraseña BIP-39 fuerte y única. Aquí matizan: es una barrera independiente que protege los fondos, pero no repara la semilla. Si esa contraseña se filtra alguna vez, vuelves a estar expuesto.
Qué NO está afectado. El resto de productos de Coinkite —Tapsigner, Opendime y Satscard— usan bases de código distintas y no tienen este problema.
Tampoco lo tienen las Coldcard Mk1, ni las Mk2 y Mk3 con firmware anterior a la versión 4.0.0: esas todavía usaban el generador por hardware, que es justo lo que se rompió después.
Si quieres entender bien qué es exactamente lo que se generó mal y por qué es la pieza que lo sostiene todo, lo explicamos en la diferencia entre clave privada y frase de recuperación.
La lección que deja
Este caso desmonta una idea muy extendida: que una cartera física, desconectada y guardada bajo llave, es el final del problema. No lo es. Con la semilla generada por el propio aparato, estás confiando toda tu seguridad a un único fabricante y a un único generador de números, y no tienes forma de comprobar desde fuera si ese generador hace bien su trabajo.
De ahí que las dos recomendaciones que aquí funcionaron sean precisamente las que no dependen del aparato: aportar entropía propia con dados, y usar configuraciones multifirma donde ninguna llave sola basta. Ambas parecen paranoia hasta el día en que dejan de parecerlo.
Coinkite, por su parte, ha detenido los envíos y ha declarado que destruirá el material afectado que le quedaba en stock.
Fuentes
