Fallo de Coldcard: por qué Mk3 se vacía y Mk4 resiste

Un error de configuración de compilación introducido en marzo de 2021 dejó las semillas generadas por las carteras Coldcard con 40 bits de entropía efectiva en los modelos Mk2 y Mk3, y unos 72 bits en Mk4, Mk5 y Q, en lugar de los 128 previstos. El 30 de julio de 2026, el mismo día en que el fallo se hizo público, alguien barrió 1.083 bitcoin de 1.196 direcciones en 41 minutos. Cinco días después, Galaxy Research contabiliza hasta 2.055 bitcoin bajo sospecha —unos 130 millones de dólares—, más de 7.700 direcciones afectadas y al menos quince atacantes independientes trabajando en paralelo. El firmware corregido salió el 31 de julio y no recupera un solo satoshi. Este artículo hace las cuentas que separan los 40 bits de los 72, explica por qué el parche no puede ayudar a quien ya está expuesto y señala la razón concreta por la que cinco años de firmware abierto y auditado no detectaron nada.

¿Qué falló exactamente en el firmware de Coldcard?

El elemento seguro —el chip aislado que custodia las claves— incluye un generador de aleatoriedad por hardware (el RNG), un circuito que extrae bits impredecibles de ruido físico. MicroPython, el intérprete sobre el que se ejecuta el firmware, trae además un generador pseudoaleatorio por software. Al integrar una biblioteca criptográfica nueva en marzo de 2021, el desarrollador puso a cero la macro MICROPY_HW_ENABLE_RNG esperando desactivar las dos implementaciones. La condición de compilación que la comprobaba —el guard— estaba escrita como #ifndef —«si la macro no está definida»— en lugar de comprobar si su valor era distinto de cero. La macro estaba definida, valía cero, y el guard dejó compilar igualmente el sustituto por software. Desde ese momento, la generación de semillas pedía aleatoriedad al chip físico y se la servía, en silencio, un algoritmo determinista. El sustituto existía en MicroPython desde mayo de 2018 sin culpa alguna —es una pieza legítima para placas sin hardware criptográfico—; lo que cambió en 2021 fue que entró en la ruta de semillas de un aparato que sí tenía ese hardware y que se vendía por tenerlo.

El término técnico es entropía: la medida de cuántos puntos de partida distintos puede tener el proceso, expresada en bits. Ciento veintiocho bits describen unos 3,4 × 10³⁸ puntos de partida posibles. Cuarenta bits describen 1,1 × 10¹². Sobre el papel, 40 frente a 128 parece un factor de tres; en espacios de búsqueda los separa un factor de 2⁸⁸, una cifra de veintisiete dígitos. Y ese detalle explica el silencio de cinco años y cuatro meses: un generador pseudoaleatorio con 40 bits de estado interno supera todas las pruebas estadísticas de aleatoriedad que existen. Su salida es indistinguible de la de un chip físico para cualquier test de uniformidad, de correlación o de compresibilidad. Lo único pequeño es el conjunto de semillas de partida. El código criptográfico auditado era correcto y el algoritmo no tenía ningún defecto. El binario compilado desde marzo de 2021, sencillamente, nunca lo llamaba.

¿Por qué las semillas de 40 bits se están vaciando y las de 72 no?

Los dos niveles de entropía son dos problemas de coste computacional separados por un factor de unos cuatro mil millones, casi diez órdenes de magnitud. Probar un candidato cuesta bastante más que un hash. El atacante recorre los estados posibles del generador, y por cada uno tiene que derivar la semilla, pasarla por la función de estiramiento de claves que define el estándar BIP-39 —PBKDF2 con HMAC-SHA-512 y 2.048 iteraciones, es decir, unas 4.096 compresiones SHA-512—, derivar el árbol de claves BIP-32, generar las primeras direcciones y cotejarlas con el conjunto de direcciones con saldo. La operación cara y no paralelizable dentro de cada candidato es el estiramiento: existe justamente para encarecer este tipo de búsqueda.

Tomando una tarjeta gráfica de gama alta actual, del orden de 3.000 millones de compresiones SHA-512 por segundo, salen unos 730.000 candidatos por segundo y por tarjeta. Las cuentas quedan así.

Los 40 bits explican el barrido de 41 minutos: la parte cara del trabajo —recorrer el espacio y construir la tabla de claves derivadas— se hace una vez, fuera de línea, y puede llevar días o semanas; el gasto posterior de las direcciones es inmediato. Los 72 bits de las Mk4, Mk5 y Q, con los mismos supuestos, quedan fuera del alcance de cualquier actor concebible hoy, incluido un Estado: ni un millón de tarjetas gráficas dedicadas en exclusiva bajarían la cifra de la escala del siglo.

El cálculo da por supuesto que los 72 bits residuales son independientes y uniformes —proceden de la entropía que los dos elementos seguros del aparato, SE1 y SE2, añaden por su cuenta— y que ningún dato lateral reduce el espacio de búsqueda. Si un dato lateral acotara la fecha de creación de la semilla, el espacio efectivo caería y la cuenta cambiaría por completo. No hay pruebas públicas de que ocurra, pero es la única puerta por la que el segundo nivel entraría en el radio de acción.

Esto sitúa en su contexto la afirmación más citada desde el 31 de julio. Alex Thorn, responsable de investigación de Galaxy, sostiene que toda dirección de firma simple (sin multifirma) creada tras el fallo de marzo de 2021 acabará vaciada, y que es cuestión de tiempo. La aritmética respalda esa frase sin matices para el nivel de 40 bits. Para el de 72 no la respalda con la tecnología conocida, salvo que se rompa el supuesto de independencia. De esa distinción depende si un propietario tiene que actuar hoy mismo o puede planificar una migración ordenada esta semana.

¿Cuánto se ha robado a las Coldcard y por qué cada medio da una cifra distinta?

Entre el 31 de julio y el 4 de agosto han circulado cinco cifras principales, del orden de 38 a 130 millones de dólares. No se contradicen: fotografían momentos distintos de un contador abierto y, además, mezclan dos variables en un mismo titular.

La distancia entre lo confirmado y lo que está bajo sospecha —459 bitcoin, más de una cuarta parte de lo confirmado— es un problema de atribución. Atribuir un barrido a este fallo exige demostrar que la dirección vaciada pertenece a la cohorte de semillas débiles, y eso se hace con heurísticas de agrupación en cadena. Cuando el vaciado es masivo, simultáneo y sigue el patrón de las oleadas, la atribución es sólida. Cuando es un movimiento aislado de una dirección antigua, encaja igual de bien con un propietario que traslada sus fondos por precaución tras leer la noticia. El contador de direcciones bajo sospecha incluye, por definición, a víctimas y a gente que se está poniendo a salvo.

Los titulares en dólares se mueven además por su cuenta: las conversiones implícitas en las cifras publicadas van de unos 65.100 dólares por bitcoin el 2 de agosto a unos 62.700 el 4. Parte de la variación del titular se explica sin que se haya robado un satoshi más, y parte del robo real queda enmascarada por la caída del precio. Para medir el daño real hay que leer la serie en bitcoin: 1.083, 1.367 y 1.596 confirmados.

¿Por qué actualizar el firmware no recupera ni un bitcoin?

El fabricante, Coinkite, lo dice sin rodeos en su aviso del 31 de julio: actualizar el firmware no cambia ni repara una semilla existente. La frase es el centro del caso. En el software convencional, un parche cierra la ventana. El fallo vive en el código, se sustituye el código y el problema desaparece para todo el mundo a la vez, sin que el usuario tenga que entender nada. Un fallo en la generación de claves rompe ese modelo: lo comprometido no es el programa, es un número que el programa produjo hace años y que desde entonces vive fuera de su alcance. Está grabado en una placa de acero dentro de una caja fuerte o repartido en participaciones de un esquema de recuperación. El parche no llega a ese objeto. Solo llega al dispositivo, y solo para las semillas que se creen a partir de ahora.

Debajo hay una ironía que contradice el argumento de venta de toda la categoría. La propiedad por la que se compra una cartera de hardware es que la clave nunca toca una red: se genera dentro y se queda dentro. Esa misma propiedad impide corregirla. Un servicio en la nube que descubre un fallo de generación de claves rota las de todos sus usuarios en una noche, sin preguntar. Un fabricante de carteras no tiene ningún canal hacia un aparato guardado en un cajón: su única vía de contacto con el propietario es la prensa. El aislamiento que se paga como defensa es lo que convierte la remediación en un proceso manual, lento y necesariamente incompleto.

Es la forma extrema de la brecha entre detectar y parchear: el parche existe, es gratuito, salió al día siguiente de la divulgación y no reduce en nada la exposición del parque instalado. La promesa de la autocustodia siempre fue la responsabilidad plena del propietario. Este episodio enseña la otra mitad de ese trato: la responsabilidad de arreglarlo también.

¿Qué añade este caso a los riesgos conocidos de la autocustodia?

La lista de límites de la autocustodia lleva años escribiéndose, y en este blog la hemos levantado pieza a pieza: tener las claves no evita firmar una autorización maliciosa —el usuario que perdió unos 282 millones de dólares desde almacenamiento en frío lo demostró en el análisis de las aprobaciones de tokens—, tampoco cubre los fondos depositados en un puente comprometido, como en el robo de 577 millones a Drift y Kelp, ni alcanza a la infraestructura centralizada que sostiene protocolos anunciados como descentralizados. Todos esos límites comparten una estructura: el usuario actúa, y el fallo entra por la puerta que él abrió. De ahí que el consejo estándar sea siempre de conducta —no firmes lo que no entiendas, no teclees la semilla, no la fotografíes.

Este caso no tiene esa estructura. Las víctimas no firmaron nada, no expusieron la semilla, no la introdujeron en ninguna web ni la sacaron del dispositivo. Hicieron exactamente lo que prescribe la doctrina de la autocustodia y la clave nació comprometida, cinco años antes de que nadie lo supiera. Ninguna disciplina del usuario habría cambiado el resultado, porque el fallo ocurrió aguas arriba, en la cadena de compilación del fabricante, antes de que el aparato saliera de fábrica.

Con una excepción que cierra el círculo, y es la única parte que está en manos del usuario. La única práctica que salvó fondos es la que suele describirse como excesiva: aportar cincuenta tiradas de dado durante la creación de la semilla. Quien lo hizo conserva sus 128 bits, porque esa entropía la puso él y no el generador defectuoso. Es el único tramo del proceso en el que el usuario no hereda la cadena de suministro del fabricante. El resto del parque —quienes confiaron en el generador, que es exactamente lo que el aparato promete— depende hoy de cuántos bits le tocaron según el modelo.

¿Quién está barriendo las Coldcard y por qué eso alarga el peligro?

El barrido coordinado inicial se ha fragmentado: Galaxy identificó tres oleadas sin poder determinar si había un mismo autor detrás y, a 4 de agosto, cuenta al menos quince actores independientes. Thorn lo describe como un tumulto abierto de actores autónomos e imitadores.

La forma de las oleadas habla por sí sola. La primera se llevó 1.083 bitcoin de 1.196 direcciones: casi un bitcoin por dirección. La tercera se llevó 208 bitcoin de 1.912 direcciones: una décima parte por dirección. Los saldos grandes se agotaron en los primeros minutos y lo que queda es la cola larga. Una vez recorrido el espacio de búsqueda, el coste marginal de vaciar una dirección más es prácticamente cero. La inversión cara ya está amortizada y la lista de claves derivadas es un activo reutilizable. Eso explica por qué se suman imitadores en lugar de agotarse el fenómeno, y es compatible con que la lista circule.

Quien tuviera un saldo grande en una semilla de 40 bits no tuvo ninguna oportunidad: se lo llevaron antes de que existiera el aviso público. Quien tenga un saldo pequeño sigue teniendo tiempo, pero es también quien menos probabilidades tiene de haberse enterado y quien tiene el dispositivo en un cajón desde hace años precisamente porque le dijeron que eso era lo seguro. Mientras queden direcciones sin migrar y la lista amortizada siga en manos de quince actores o más, cada día suma vaciados nuevos.

¿Encontró el fallo una inteligencia artificial?

Circula con fuerza y conviene separar lo dicho de lo publicado. Lo que consta es una declaración del cofundador de Coldcard, NVK, advirtiendo de que la revisión de código asistida por modelos de lenguaje encuentra hoy fallos latentes a una velocidad que supera a los especialistas más veteranos. Es una advertencia sobre el estado del oficio, formulada como diagnóstico del presente y dirigida a otros desarrolladores. Varios medios la han convertido en un titular que atribuye este ataque concreto a una IA. No se ha publicado ninguna prueba técnica que sostenga esa atribución, y sin análisis forense público la afirmación no es verificable: a día de hoy ninguna firma ha atribuido públicamente un exploit cripto a un agente de IA.

La pregunta sigue mereciendo estar abierta por un motivo de secuencia. El fallo estuvo cinco años y cuatro meses en un firmware de código abierto, revisado por una comunidad que audita cada línea de criptografía con lupa, y nadie publicó nada. El primer actor documentado que lo encontró fue el que lo usó: el barrido empezó a las 01:10 UTC del 30 de julio, en los bloques 960.183 a 960.191, y el primer aviso público del fabricante llegó a las 22:50 UTC de ese mismo día, casi veintiuna horas después. Esa cronología —hallazgo y explotación por delante de la divulgación, tras un lustro de silencio— es lo que alimenta la especulación, con o sin pruebas.

¿Qué debe hacer hoy quien tenga una Coldcard?

La condición que determina la exposición es la versión de firmware con la que se generó la semilla, no la que tenga el aparato ahora.

El procedimiento que indica el fabricante consta de dos pasos que no son intercambiables:

1. Actualizar el firmware a la versión corregida del modelo.
2. Generar una semilla completamente nueva y trasladar los fondos a ella.

Saltarse el segundo deja el dinero exactamente donde estaba. Quedan fuera del problema dos casos concretos. El primero, quien aportó al menos cincuenta tiradas con un dado no trucado, independientes y nunca registradas durante la creación de la semilla: el fabricante estima que entre cincuenta y noventa y ocho tiradas devuelven los 128 bits completos, porque esa entropía la puso el usuario y no el generador defectuoso. El segundo, quien protege los fondos con una frase de paso BIP-39 fuerte y única, con la advertencia expresa de que una frase corta, común, con patrón, tomada de una cita o reutilizada no sirve, y de que aun así conviene migrar. Tampoco están afectadas las semillas importadas desde otro dispositivo ni las creadas después del parche.

Un aviso de sentido común sobre lo que viene después: episodios así generan una segunda ola de herramientas de «asistencia a la migración», comprobadores de exposición y supuestos servicios de recuperación que piden la frase semilla. Ningún procedimiento legítimo de migración necesita que se introduzca una semilla existente en una página web o en una aplicación de escritorio. Comprobar si una dirección está afectada no requiere la clave; cualquier servicio que solicite la semilla debe tratarse como un intento de robo.

¿Qué deja este caso para el resto de la industria?

La respuesta habitual —auditar más— no habría servido: el código auditado era correcto y la salida del generador equivocado habría pasado cualquier prueba estadística, porque lo único que un algoritmo determinista no puede producir es más puntos de partida de los que caben en su estado interno. La superficie que se audita y la que se ejecuta se separaron, como en el fix de Gnosis Pay que nunca llegó al contrato desplegado.

Lo que sí habría funcionado es una comprobación que casi nadie hace: verificar, sobre el binario que sale de fábrica, que la llamada a la fuente de aleatoriedad termina realmente en el chip que se está vendiendo. Es una cuestión de enlazado y de compilación reproducible, no de criptografía. Una aserción en tiempo de ejecución que falle si el símbolo del generador por hardware no está presente cuesta unas pocas líneas y habría convertido un fallo de cinco años en un dispositivo que no arranca el primer día. El coste de no hacerlo va ya por 130 millones de dólares y sigue subiendo.

Fuentes y enlaces: Coinkite — Technical Deep Dive into the Entropy Issue · Versiones afectadas por modelo y condiciones de excepción (dados y frase de paso) · CoinDesk — 70 millones en un ataque que nunca tocó los dispositivos (1-ago-2026) · CoinDesk — Tres oleadas y 4.585 direcciones (2-ago-2026) · Crypto Times — Galaxy: 15 atacantes y hasta 2.055 BTC (4-ago-2026) · crypto.news — Estimación de Galaxy sobre el total sustraído · Bitcoin Magazine — Firmware corregido y la declaración de NVK sobre revisión asistida por IA · The Hacker News — Cronología del barrido de 41 minutos · Protos — Cronología con horas y bloques del barrido inicial · Fortune — Recuento del 3 de agosto · CoinDesk — Primer recuento y el debate sobre autocustodia (31-jul-2026)