Un fallo de firmware en Coldcard permite robar 89 millones de dólares en BTC

Un ataque contra Coldcard, una de las carteras de hardware más utilizadas en Bitcoin, ha puesto al descubierto un fallo crítico en la generación interna de claves. En tres oleadas, los atacantes aprovecharon una debilidad en la creación de la semilla (seed) en firmwares afectados y sustrajeron aproximadamente 1.367 BTC —unos 89 millones de dólares— desde miles de direcciones. No se trató de un phishing ni de una brecha en un exchange: el punto de entrada fue el propio proceso de generación de claves del dispositivo, basado durante años en una aleatoriedad insuficiente. Cronología del robo: tres oleadas en cuestión de horas El 30 de julio de 2026 comenzó el vaciado de fondos desde carteras Coldcard. En la primera oleada desaparecieron 594 BTC (aprox. 38 millones de dólares) desde unas 500 carteras en apenas 25 minutos. Los atacantes fueron a por los saldos más altos: según Chainalysis, recaudaron más de 30 millones de dólares en los primeros 10 minutos, y una única cartera perdió alrededor de 1,8 millones de dólares. Ese mismo 30 de julio se produjo una segunda oleada que elevó el total a 1.082 BTC (aprox. 70 millones de dólares) repartidos en 1.196 direcciones en un periodo de 41 minutos. Para el 2 de agosto, el balance acumulado ascendía a 1.367 BTC (aprox. 89 millones de dólares) desde 4.585 direcciones. El barrido no fue aleatorio. La selección de objetivos y el orden de ejecución sugieren que el operador ya había identificado direcciones valiosas antes de iniciar el robo. El drenaje continuó durante casi 30 horas antes de que Coinkite publicara su primera advertencia pública. Posteriormente, Galaxy Research identificó alrededor de 600 direcciones presuntamente vinculadas a los atacantes y las trasladó a investigadores. La firma también señaló patrones operativos similares entre las oleadas 1 y 2, mientras que la tercera mostró métodos de cobro distintos, lo que abre la puerta a que otro actor aprovechara la misma debilidad. La clave del incidente: semillas débiles desde el momento de creación El aspecto más grave es que el atacante no necesitó acceso físico a los dispositivos ni control remoto. El problema estaba en la semilla generada cuando los usuarios inicializaban la cartera: si la semilla nacía con baja entropía, podía reconstruirse fuera de línea y, con ella, derivar las claves privadas para vaciar los fondos. En términos prácticos, los usuarios compran una cartera de hardware para aislar sus claves de amenazas online. En este caso, el propio dispositivo generó claves con aleatoriedad insuficiente, dejando una debilidad estructural desde el primer día. Cómo se introdujo el fallo y por qué pasó desapercibido cinco años Según el análisis publicado por distintas fuentes técnicas, el 1 de marzo de 2021 un cambio de código modificó la función de generación de seeds: se sustituyó ckcc.rng_bytes, que utilizaba el generador de números aleatorios por hardware del chip STM32, por ngu.random.bytes, un PRNG (generador seudoaleatorio) por software alimentado por entradas deterministas. Ese PRNG dependía de datos como el número de serie del dispositivo, valores de temporizador internos y el historial de llamadas previas al RNG. El firmware procesaba esas entradas con hashing criptográfico SHA256d. El hash puede mezclar datos existentes, pero no crea aleatoriedad nueva: si el sistema parte de un espacio de entrada limitado, el espacio de salida también lo estará. Coinkite indica que, a partir de la versión v4.0.0 (publicada el 17 de marzo de 2021), las seeds generadas en Mk2 y Mk3 quedaron reducidas a aproximadamente 40 bits de entropía. En Mk4, Mk5 y Q se añadió entropía adicional desde un "secure element", elevando la entropía efectiva a alrededor de 72 bits. Aun así, ambas cifras quedan por debajo del nivel de seguridad de 128 bits que se espera en la generación de semillas para Bitcoin. El fallo se mantuvo durante cinco años de actualizaciones, revisiones y una auditoría asistida por IA realizada pocas semanas antes del ataque sin que nadie lo detectara. Zach Herbert, CEO de Foundation Devices, atribuyó la introducción del bug a una gran reescritura de firmware en marzo de 2021 vinculada a un cambio de librerías criptográficas y a una revisión de licencias, más que a una decisión explícita de diseño de seguridad. Cómo pudieron robar: fuerza bruta sobre seeds de 40 bits Con entropía de 40 bits, el universo de posibles seeds ronda 2^40 (aprox. un billón de posibilidades). Aunque suena enorme, es un espacio abordable con hardware moderno, especialmente si el atacante reduce el objetivo a seeds generadas en el periodo vulnerable 2021–2026 y si puede acotar variables del dispositivo (UID, estado de temporizador, secuencias de llamadas previas). El procedimiento descrito por analistas se basa en generar, fuera de línea, seeds candidatas; derivar direcciones de Bitcoin; comparar con la información pública de la cadena; y, cuando aparece una coincidencia con fondos, reconstruir la clave privada y barrer el saldo. En Mk4, Mk5 y Q, con ~72 bits de entropía, el ataque sería mucho menos viable, pero sigue por debajo del estándar de referencia. Block (la empresa de Jack Dorsey) describió además un diseño de tipo "fail-open" en el que ciertas condiciones de arranque podrían reducir la búsqueda a 2^32 valores. No se ha confirmado explotación masiva de esa vía. Quién está en riesgo: modelos, firmwares y nivel de exposición El factor determinante es la versión de firmware instalada en el momento en que se creó la semilla. Actualizar el firmware hoy no repara una seed antigua: la debilidad queda incrustada en el número ya generado. La actualización solo protege la creación de seeds futuras. Según el desglose publicado, el riesgo por modelo y firmware queda así: - Mk2 / Mk3: vulnerable si la seed se generó con v4.0.0 / v4.0.1 hasta v4.1.9; entropía efectiva ~40 bits; corrección en v4.2.0+; riesgo máximo y explotación confirmada. - Mk4 / Mk5: vulnerable si la seed se generó antes de v5.6.0 (standard) / antes de v6.6.0X (Edge); entropía ~72 bits; corrección en v5.6.0+ / v6.6.0X+; sin explotación confirmada a gran escala. - Q: vulnerable si la seed se generó antes de v1.5.0Q (standard) / antes de v6.6.0QX (Edge); entropía ~72 bits; corrección en v1.5.0Q+ / v6.6.0QX+. Hay una excepción relevante: quienes añadieron al menos 50 tiradas de dado independientes y privadas durante la configuración aportaron una fuente externa de entropía real que neutraliza esta debilidad concreta. Una passphrase BIP39 fuerte eleva el coste del ataque, pero no "arregla" la seed subyacente; por eso, Coinkite recomienda igualmente migrar fondos si la seed se generó en firmware afectado. Respuesta de Coinkite: parches, guía de migración y críticas Coinkite publicó sus primeras alertas el 30 y el 31 de julio, aproximadamente 30 horas después de iniciarse el barrido, y lanzó firmware corregido para todos los modelos: v4.2.0 (Mk3), v5.6.0 (Mk4/Mk5) y v1.5.0Q (Q). También difundió un análisis técnico y una guía de migración, y el 1 de agosto amplió el aviso para incluir el impacto en Mk4, Mk5 y Q por la reducción de entropía. La actuación ha recibido críticas por dos motivos principales: la permanencia del bug durante cinco años pese a revisiones y una auditoría asistida por IA, y la demora en la comunicación pública mientras el atacante seguía drenando fondos. Kevin Loaec, investigador de Wizardsardine, añadió que en configuraciones multisig con claves derivadas de Coldcard afectadas debería considerarse exposición y rotación de claves, un punto que el aviso no cubre en profundidad. Qué deben hacer los usuarios: migrar, no solo actualizar Actualizar el firmware no asegura una cartera ya existente si su seed se creó con el código vulnerable. La medida efectiva consiste en generar una seed nueva en firmware corregido y mover todos los BTC a direcciones derivadas de esa nueva seed. Proceso recomendado de migración: 1) Actualizar el firmware a la última versión corregida correspondiente al modelo y canal, verificando la descarga desde la web oficial de Coinkite. 2) Generar una seed totalmente nueva en el propio dispositivo ya actualizado (no restaurar ni importar la antigua). Si es posible, añadir al menos 50 tiradas de dado independientes y privadas. 3) Verificar la copia de seguridad de la seed en el dispositivo y comprobar que la dirección de recepción coincide entre el software de cartera y la pantalla de Coldcard. 4) Transferir todo el saldo desde las direcciones antiguas a las nuevas, verificando en el dispositivo dirección y detalles antes de firmar. 5) Confirmar en un explorador de bloques que las transacciones están confirmadas, que las direcciones antiguas quedan a cero y que el nuevo monedero refleja el total. 6) Destruir de forma segura la copia de la seed antigua solo tras confirmar que el acceso al nuevo monedero es correcto. Cada migración implica comisiones on-chain; en un traslado urgente conviene evitar comisiones demasiado bajas. En multisig, la complejidad aumenta: hay que rotar cualquier clave derivada de seeds afectadas y validar la nueva política antes de mover importes relevantes. Impacto más amplio: la entropía también es seguridad de custodia propia El caso subraya dos requisitos para la autocustodia: control de claves y generación de claves con aleatoriedad de alta calidad. La industria ha insistido más en lo primero ("not your keys, not your coins") que en lo segundo. Este incidente se suma a otros fallos recientes de PRNG en cripto, como Milk Sad (2023) e Ill Bloom (2026), donde el problema estaba en la generación de claves, un paso que el usuario medio no puede auditar. También reabre el debate entre firmware público y firmware cerrado: el código de Coldcard era inspeccionable, pero el fallo permaneció oculto durante años. La disponibilidad del código no garantiza seguridad, aunque es condición necesaria para auditorías comunitarias reales. CoinDesk ha señalado que episodios como este pueden empujar a parte de los inversores hacia ETFs de Bitcoin, que eliminan el riesgo operativo de gestionar claves, a cambio de depender de un custodio regulado. Blockaid, por su parte, indicó que en el primer semestre de 2026 la mayoría de pérdidas cripto provinieron de claves comprometidas y fallos operativos, no de exploits en smart contracts, encajando el ataque de Coldcard en esa tendencia. Preguntas frecuentes - ¿Está comprometida mi Coldcard? Puede estarlo si generaste la seed en Mk2 o Mk3 con firmware v4.0.0 a v4.1.9 sin añadir suficientes tiradas de dado. Mk4, Mk5 y Q anteriores a los parches quedan en ~72 bits de entropía: no hay explotación masiva confirmada, pero están por debajo del estándar esperado. La recomendación es actualizar, crear seed nueva y migrar fondos. - ¿Actualizar el firmware lo arregla? No para seeds ya creadas. La actualización corrige la generación futura; para estar protegido hay que crear una seed nueva y mover los BTC. - ¿Ledger y Trezor están afectados? No. Ledger, Trezor y Block (Bitkey) indican que usan sistemas de generación de entropía distintos. - ¿Cuánto se robó? A 2 de agosto de 2026, alrededor de 1.367 BTC (unos 89 millones de dólares) en tres oleadas, afectando a 4.585 direcciones. - ¿Quién es el atacante? No está identificado. Galaxy Research cree que las oleadas 1 y 2 podrían ser del mismo operador; la tercera muestra un comportamiento distinto. Se reportaron unas 600 direcciones sospechosas. - ¿Las tiradas de dado me protegen? Sí, si se realizaron al menos 50 tiradas independientes y privadas durante la generación de la seed. Coinkite afirma que en ese caso el riesgo por esta vulnerabilidad es mínimo. Este texto tiene fines informativos y educativos y no constituye asesoramiento financiero, de inversión, legal ni de seguridad. Realiza tu propia investigación antes de tomar decisiones relacionadas con criptoactivos.