Introducción
El 30 de julio de 2026, un atacante no identificado barrió 1 196 direcciones Bitcoin en menos de tres cuartos de hora, sustrayendo 1 082 bitcoins valorados en aproximadamente 70 millones de dólares al tipo de cambio del momento. Las estimaciones más recientes elevan el total a más de 88 millones de dólares, distribuidos entre 4 585 direcciones comprometidas. No se trató de phishing ni de ingeniería social: fue la consecuencia directa y predecible de un generador de números aleatorios defectuoso, presente en el firmware del monedero hardware Coldcard desde marzo de 2021.
Una macro mal evaluada, cinco años de vulnerabilidad silenciosa
Coldcard es fabricado por la empresa canadiense Coinkite. El fallo tiene su origen en un error de integración de firmware: la variable de configuración MICROPY_HW_ENABLE_RNG estaba establecida en cero en el perfil de producción. La biblioteca libngu verificaba la existencia de la macro en lugar de su valor efectivo, lo que provocaba que la compilación cayera silenciosamente sobre el PRNG software de MicroPython —un algoritmo denominado Yasmarang— en lugar de utilizar el generador hardware del chip STM32.
Este PRNG de respaldo se inicializaba únicamente a partir del identificador único del chip y de registros de temporización, sin recolección de entropía adicional tras la inicialización. La entropía efectiva caía así a aproximadamente 40 bits en los modelos Mk3, y 72 bits en los Mk4, Mk5 y Q, frente a los 128 bits exigidos para una frase semilla BIP-39 estándar. La diferencia es determinante: cada bit de entropía faltante divide por dos el espacio de búsqueda disponible para un atacante.
De la debilidad matemática a la explotación en tiempo real
Un atacante que conozca el rango de entradas del PRNG puede reproducir offline todos los flujos de salida candidatos, derivar las correspondientes direcciones Bitcoin y cruzarlas con los datos públicos de la blockchain para identificar aquellas que contienen fondos. Galaxy Research, que cartografió el ataque, confirmó este patrón de explotación. Aproximadamente 600 direcciones fueron notificadas a las autoridades federales estadounidenses. Los modelos afectados comprenden las versiones de firmware 4.0.0 a 4.1.9 en Mk2 y Mk3, y todas las versiones anteriores a 5.6.0 en Mk4 y Mk5.
Un parche con limitaciones explícitas
Coinkite publicó actualizaciones de emergencia el 31 de julio para todos los modelos afectados. La advertencia que las acompaña es inequívoca: instalar el parche no sanea una semilla existente. Los usuarios deben generar una nueva semilla sobre el firmware parcheado y transferir sus fondos a las nuevas direcciones. Solo quienes recurrieron a lanzamientos de dados físicos —al menos cincuenta lanzamientos independientes— durante la creación inicial de su monedero están fuera de peligro.
Lo que los equipos de TI deben extraer de este incidente
Este incidente ilustra una clase de vulnerabilidades particularmente temible: los fallos silenciosos, sin anomalía detectable durante años, cuya explotación se vuelve casi instantánea en cuanto se dan las condiciones adecuadas. La calidad de las fuentes de aleatoriedad es un requisito no negociable para cualquier sistema criptográfico, ya se trate de monederos hardware, módulos HSM corporativos o generadores de certificados TLS.
Para los CISO y arquitectos de seguridad, la lección es directa: los parámetros de firmware relacionados con la generación de claves deben someterse a pruebas de integración explícitas —no a simples comprobaciones de presencia de macros—. Cada actualización de la cadena de herramientas debería desencadenar una revisión de las bibliotecas criptográficas embebidas. El tiempo entre el descubrimiento de una clave débil y su explotación tiende a cero: 41 minutos acaban de recordarlo de manera brutal.