Hackeo de Coldcard drena $89 millones en BTC debido a una vulnerabilidad en el firmware

El hackeo de Coldcard reveló una falla crítica en uno de los monederos de hardware más confiables de Bitcoin. Durante tres olas de ataque, los atacantes explotaron la generación débil de semillas en el firmware afectado y vaciaron aproximadamente 1,367 BTC, valorados en alrededor de $89 millones, desde miles de direcciones.

A diferencia de un fraude de phishing típico o una brecha en el exchange, este ataque apuntó al proceso interno de generación de claves del monedero. Específicamente, un bug de firmware de cinco años de antigüedad produjo semillas con aleatoriedad insuficiente, permitiendo a los atacantes reconstruir las claves privadas fuera de línea y transferir los fondos de los usuarios. Por lo tanto, este artículo explica cómo funcionó la vulnerabilidad, qué modelos de Coldcard están en riesgo y qué deben hacer los usuarios afectados a continuación.

El 30 de julio de 2026, el hackeo de Coldcard comenzó cuando un atacante desconocido inició la extracción de bitcoin de monederos hardware Coldcard. Durante la primera ola, 594 BTC, valorados en aproximadamente $38 millones, desaparecieron de alrededor de 500 monederos en solo 25 minutos. El atacante priorizó primero los monederos de mayor valor. Una segunda ola aumentó las pérdidas a 1.082 BTC, valorados en aproximadamente $70 millones, en 1.196 direcciones dentro de 41 minutos. Para el 2 de agosto, tres olas de ataque habían extraído un total combinado de 1.367 BTC, valorados en aproximadamente $89 millones, de 4.585 direcciones.

El atacante no seleccionó monederos al azar. Según Chainalysis, el operador priorizó los objetivos más ricos y recolectó más de $30 millones durante los primeros 10 minutos. Un solo monedero perdió aproximadamente $1.8 millones. Este patrón sugiere que el atacante ya había identificado direcciones valiosas y ejecutó el robo en una secuencia deliberada.

Mientras tanto, el amplio movimiento continuó durante casi 30 horas antes de que Coinkite publicara su primera advertencia pública. Galaxy Research identificó posteriormente aproximadamente 600 direcciones sospechosas de atacantes y las reportó a los investigadores. La firma de investigación también encontró patrones operativos similares en las dos primeras olas, mientras que la tercera ola utilizó métodos de recolección diferentes.

Lo más importante, el ataque a Coldcard no fue un ataque de phishing, una brecha en el exchange ni un caso de robo físico de las claves privadas de los usuarios. El atacante nunca necesitó acceso directo a los dispositivos Coldcard afectados. En cambio, las billeteras generaron semillas débiles cuando los usuarios las inicializaron, lo que permitió al atacante reconstruir las claves privadas sin conexión.

Esa distinción hace que el incidente sea especialmente grave. Los usuarios compraron dispositivos Coldcard para aislar sus claves de Bitcoin de las amenazas en línea. Sin embargo, el hardware generó esas claves con aleatoriedad insuficiente. En otras palabras, el producto diseñado para proteger a los usuarios creó la vulnerabilidad por sí mismo. El fallo de seguridad existió desde el momento en que los monederos afectados generaron sus semillas.

Imagina comprar una cerradura de alta seguridad que promete generar cada combinación con un verdadero generador físico aleatorio. En cambio, el fabricante instala una fórmula predecible que produce combinaciones a partir de un conjunto limitado de entradas. Una vez que alguien descubre esa fórmula, puede probar cada combinación posible hasta encontrar la tuya. Eso es esencialmente cómo se volvió posible el hackeo de Coldcard.

El 1 de marzo de 2021, un solo commit de código modificó la función responsable de generar las semillas de los monederos. Originalmente, ckcc.rng_bytes recopilaba aleatoriedad genuina del generador de números aleatorios por hardware integrado en el chip STM32 del dispositivo. Sin embargo, los desarrolladores lo reemplazaron con ngu.random.bytes, un generador de números pseudoaleatorios basado en software que dependía de entradas deterministas.

Específicamente, el PRNG del software utilizó el número de serie del dispositivo, los valores del temporizador interno y el historial de llamadas anteriores al RNG. El firmware luego procesó esas entradas con el cifrado criptográfico SHA256d. Aunque el hashing puede dispersar datos existentes, no puede crear nueva aleatoriedad. Por lo tanto, si el sistema comienza con solo 2^40 entradas posibles, aún puede producir solo 2^40 salidas posibles.

Como resultado, los dispositivos Mk3 afectados generaron semillas con aproximadamente 40 bits de entropía. Mientras tanto, los dispositivos Mk4, Mk5 y Q recibieron entrada adicional de un elemento seguro, lo que elevó su entropía efectiva a aproximadamente 72 bits. Sin embargo, ambas cifras permanecieron por debajo del nivel de seguridad de 128 bits esperado en la generación de semillas de bitcoin.

El CEO de Foundation Devices, Zach Herbert, dijo que el error se introdujo durante una reescritura importante del firmware en marzo de 2021 que reemplazó el código GPL restante con nuevas bibliotecas criptográficas. En otras palabras, el cambio formó parte de una revisión de licencias en lugar de una decisión de seguridad deliberada.

A pesar de ello, el código defectuoso permaneció activo durante cinco años. Coinkite realizó una auditoría de firmware asistida por IA solo semanas antes del ataque, pero la revisión no logró identificar el problema. Además, múltiples actualizaciones de firmware, incluidas versiones centradas en seguridad, también lo omitieron.

En última instancia, el monedero debería haber utilizado una fuente física de aleatoriedad para generar claves impredecibles. En cambio, utilizó una fórmula limitada y predecible. Una vez que el atacante comprendió esa fórmula, pudo comenzar a reconstruir las semillas de los usuarios y llevar a cabo el ataque a Coldcard.

El atacante detrás del hack de Coldcard no necesitó robar un dispositivo ni conectarse a él remotamente. En cambio, el atacante pudo estimar variables clave como el UID del dispositivo, el estado del temporizador y la secuencia de llamadas previas al RNG. Con esos límites, el atacante pudo reproducir flujos de salida de semillas posibles completamente sin conexión.

Luego, el atacante convirtió cada semilla candidata en direcciones de bitcoin y las comparó con datos públicos de la cadena de bloques. Este proceso funciona como probar combinaciones en una cerradura. Con aproximadamente 40 bits de entropía, las semillas afectadas provenían de un conjunto de aproximadamente un billón de posibilidades. Aunque este número parece grande, el hardware informático moderno puede buscar en dicho espacio dentro de un plazo práctico, especialmente cuando el atacante reduce el conjunto de objetivos.

El atacante probablemente se enfocó en direcciones asociadas con semillas de Coldcard creadas durante el período vulnerable de 2021 a 2026. Desde allí, el atacante generó semillas candidatas, derivó sus direcciones correspondientes y buscó coincidencias en la cadena de bloques. Una vez que una semilla candidata produjo una dirección que contenía bitcoin, el atacante obtuvo control de la clave privada correspondiente y retiró los fondos. Por lo tanto, este proceso de fuerza bruta formó el núcleo del ataque a Coldcard.

Mientras tanto, Galaxy Research encontró que las olas 1 y 2 podrían compartir el mismo operador. Sin embargo, la ola 3 mostró un comportamiento diferente en la cadena. Como resultado, otro atacante podría haber descubierto y explotado independientemente la vulnerabilidad.

Los dispositivos Mk4, Mk5 y Q tenían una entropía más fuerte de aproximadamente 72 bits. Sin embargo, aún estaban por debajo del estándar esperado de 128 bits. Block describió el diseño como una “estructura peligrosa de fallo abierto” porque ciertas condiciones de arranque podían reducir la búsqueda a solo 2^32 valores posibles. Los atacantes no han explotado esta debilidad a gran escala hasta ahora. Aun así, la estructura restante muestra que los dispositivos afectados no lograron proporcionar el nivel de aleatoriedad que los usuarios esperaban de un monedero de hardware.

El hackeo de Coldcard afecta a cada modelo de manera diferente según la versión del firmware que generó la semilla del monedero. Los dispositivos Mk2 y Mk3 enfrentan el mayor riesgo porque el firmware afectado produjo semillas con solo aproximadamente 40 bits de entropía. Mientras tanto, los dispositivos Mk4, Mk5 y Q recibieron entropía adicional de un elemento seguro, lo que elevó su seguridad efectiva a aproximadamente 72 bits. Sin embargo, ese nivel aún permaneció por debajo del estándar de 128 bits esperado para la generación de semillas de bitcoin.

Crucialmente, la versión del firmware instalada cuando el dispositivo creó la semilla determina si un usuario está expuesto al ataque de Coldcard. La versión actual del firmware no modifica la seguridad de una semilla existente. Por ejemplo, un usuario que generó una semilla en un firmware vulnerable y luego actualizó el dispositivo aún posee una semilla débil. La debilidad existe dentro del número que el dispositivo ya generó. Por lo tanto, una actualización del firmware solo protege la generación futura de semillas. No puede reparar semillas antiguas ni hacer seguras las direcciones asociadas a ellas.

Sin embargo, los usuarios que ingresaron al menos 50 tiradas de dados independientes y privadas durante la configuración de la semilla añadieron una fuente externa de entropía genuina. Esta aleatoriedad adicional anula la debilidad en el RNG del software del dispositivo. Como resultado, esos usuarios enfrentan un riesgo mínimo por esta vulnerabilidad específica. Una frase de paso BIP-39 sólida también dificulta los ataques de fuerza bruta, pero no fortalece ni repara la semilla subyacente. En consecuencia, Coinkite sigue recomendando migrar los fondos generados a partir del firmware afectado.

Finalmente, el hackeo de Coldcard no afecta a todos los monederos de hardware. Trezor, Ledger y Block, que produce Bitkey, han confirmado que sus productos utilizan sistemas diferentes de generación de entropía. Por lo tanto, este fallo específico de firmware no afecta a las semillas creadas por esos dispositivos.

Tras el hackeo de Coldcard, Coinkite publicó su primer aviso de seguridad el 30 de julio y el 31 de julio, aproximadamente 30 horas después de que comenzara el primer movimiento. La empresa luego lanzó firmware actualizado para todos los modelos afectados, incluyendo la v4.2.0 para el Mk3, la v5.6.0 para el Mk4 y Mk5, y la v1.5.0Q para el Q. Además, Coinkite publicó un análisis técnico de la vulnerabilidad y proporcionó una guía de migración para ayudar a los usuarios a transferir fondos lejos de semillas débiles.

Además, Coinkite actualizó su advertencia el 1 de agosto para reconocer que los dispositivos Mk4, Mk5 y Q también sufrieron una entropía reducida. Aunque los atacantes targetearon principalmente las semillas Mk2 y Mk3 durante el ataque a Coldcard, los modelos posteriores aún no alcanzaron el estándar de seguridad esperado de 128 bits. Al revelar el alcance más amplio y lanzar correcciones en todas las líneas de productos afectadas, Coinkite brindó a los usuarios un camino más claro hacia la seguridad de su bitcoin.

Sin embargo, la respuesta también ha generado críticas legítimas. El error permaneció en producción durante cinco años a pesar de revisiones internas, lanzamientos de firmware enfocados en seguridad y una auditoría asistida por IA realizada poco antes del ataque. Más importante aún, el saqueo continuó durante casi 30 horas antes de que Coinkite emitiera su primera advertencia pública. Como resultado, los usuarios afectados no tuvieron información oficial que les hubiera permitido migrar su bitcoin antes de que el atacante llegara a sus monederos.

Mientras tanto, las circunstancias relacionadas con el cambio original en el código han generado más preguntas. El CEO de Foundation Devices, Zach Herbert, argumenta que el error se introdujo durante una revisión de licencias en lugar de un rediseño centrado en la seguridad. Por lo tanto, el incidente ha provocado un escrutinio sobre cómo Coinkite gestionó los riesgos de seguridad durante la reescritura de 2021. Del mismo modo, el investigador de seguridad Wizardsardine Kevin Loaec dice que los usuarios deberían considerar configuraciones multisig que contengan claves de Coldcard afectadas expuestas, un problema que el aviso de Coinkite no aborda completamente.

En última instancia, Coinkite lanzó parches funcionales, detalles técnicos e instrucciones de migración después de que se hiciera pública la vulnerabilidad de Coldcard. Sin embargo, esas acciones no borran el fallo de detección de cinco años ni la advertencia retrasada que impidió que algunos usuarios protegieran sus fondos a tiempo.

Actualizar solo el firmware de su Coldcard no asegurará un monedero existente. El firmware vulnerable ya generó una semilla débil, y esa debilidad permanece incrustada en la propia semilla. Por lo tanto, los usuarios afectados deben crear una nueva semilla y transferir su bitcoin a direcciones derivadas de ella. El aviso de Coinkite y la guía de Shinobi en Bitcoin Magazine recomiendan el siguiente proceso de migración.

1. Actualice el firmware de su Coldcard. Instale el último firmware corregido disponible para su modelo específico de Coldcard y su canal de lanzamiento. Verifique que descargó el firmware desde el sitio web oficial de Coinkite antes de instalarlo.
2. Genera una semilla completamente nueva. Crea la semilla en el dispositivo actualizado en lugar de importar o restaurar la antigua. Para mayor entropía, considera utilizar al menos 50 lanzamientos de dados independientes y privados durante la generación de la semilla.
3. Verifique la nueva copia de seguridad de la semilla. Anote las nuevas palabras de la semilla en el orden correcto y complete el proceso de verificación en el dispositivo. Luego, genere una dirección de recepción y confirme que la dirección mostrada en su software de monedero coincide con la dirección displayed en la pantalla de Coldcard.
4. Transfera todo el bitcoin al nuevo monedero. Envía todos los saldos de BTC controlados por la semilla antigua a las direcciones derivadas de la nueva semilla generada. Verifica cuidadosamente la dirección de destino y los detalles de la transacción en el Coldcard antes de firmar.
5. Confirma la migración. Usa un Explorador de bloques de bitcoin confiable para verificar que las transacciones se hayan confirmado. Luego, comprueba que las direcciones antiguas no tengan bitcoin restante y que el nuevo monedero muestre el saldo transferido completo.
6. Destruye la copia de seguridad antigua de la semilla de forma segura. Solo destruye la copia antigua después de que todas las transferencias hayan sido confirmadas y hayas verificado el acceso al nuevo monedero. Elimina todas las copias físicas y digitales de la semilla comprometida para que nadie pueda volver a usarla.

No actualice el firmware y asuma que el monedero existente se ha vuelto seguro. La actualización corrige la generación futura de la semilla, pero no puede fortalecer una semilla que el dispositivo creó anteriormente. Además, cada migración requiere una transacción de bitcoin en la cadena, por lo que los usuarios deben tener en cuenta las tarifas de la red y evitar elegir una tarifa innecesariamente baja durante una transferencia urgente.

Los usuarios de multisig enfrentan una complicación adicional. Cada clave derivada de una semilla de Coldcard afectada debe ser rotada. Los usuarios deben revisar el umbral de firma del monedero, reemplazar cada clave vulnerable y verificar la nueva configuración de multisig antes de mover fondos significativos.

La autosuficiencia depende de dos requisitos de seguridad separados. Primero, los usuarios deben controlar sus claves privadas. Segundo, los monederos deben generar esas claves con aleatoriedad genuina y de alta calidad. Las empresas de monederos de hardware han enfatizado tradicionalmente el primer requisito porque respalda el principio familiar de “no tus claves, no tus monedas”. Sin embargo, han discutido mucho menos a menudo el segundo requisito. Como muestra la explotación de Coldcard, los usuarios pueden controlar completamente sus claves y aún así perder fondos si el dispositivo generó esas claves a partir de entradas predecibles.

Además, este incidente marca la tercera falla importante de un generador de números pseudoaleatorios en cripto en los últimos años, tras Milk Sad en 2023 e Ill Bloom en 2026. En cada caso, la falla ocurrió durante la generación de claves, un proceso que los usuarios comunes no podían verificar independientemente. Una interfaz de monedero puede mostrar una frase semilla válida y generar direcciones funcionales, mientras sigue confiando en una entropía peligrosamente débil debajo. En consecuencia, los usuarios pueden no descubrir el problema hasta que un atacante reconstruya la frase semilla y transfiera los fondos.

Al mismo tiempo, el incidente complica el debate sobre billeteras de hardware de código abierto y de código cerrado. Coldcard hace públicamente disponible su código fuente de firmware, aunque no libera el software bajo una licencia de código abierto permisiva completamente. Los desarrolladores podrían inspeccionar el código vulnerable, pero el error permaneció sin detectar durante cinco años. Por lo tanto, el código público no garantiza un código seguro. Sin embargo, la disponibilidad del código sigue siendo necesaria para una auditoría comunitaria significativa, ya que los investigadores no pueden inspeccionar software al que no tienen acceso.

Mientras tanto, CoinDesk ha informado que la explotación podría impulsar a algunos inversores hacia Bitcoin ETFs. Los ETF eliminan los riesgos operativos de generar, almacenar y proteger claves privadas. Sin embargo, los inversores reemplazan esos riesgos con la dependencia de un custodio regulado y una institución financiera. En otras palabras, el intercambio no elimina el riesgo de custodia. En su lugar, transfiere la responsabilidad del titular individual a un proveedor institucional.

Finalmente, Blockaid encontró que las claves comprometidas y fallas de seguridad operacional causaron la mayoría de las pérdidas de cripto durante el primer semestre de 2026, en lugar de explotaciones de contratos inteligentes. En este contexto, el incidente de Coldcard encaja en el patrón general porque el atacante apuntó al proceso de generación de claves en lugar de explotar bitcoin mismo. El almacenamiento en frío sigue siendo la opción correcta para la mayoría de los titulares de bitcoin a largo plazo. Pero “en frío” no significa “infalible”. Confía en el principio. Verifica la implementación.

Este artículo tiene fines informativos y educativos únicamente y no constituye asesoría financiera, de inversión, legal ni de seguridad. Siempre realiza tu propia investigación antes de tomar decisiones relacionadas con criptoactivos.