Coldcard y casi 600 BTC: el fallo de firmware que no era un hackeo de exchange

El peor golpe no fue a un exchange

Casi 600 bitcoins. Unos 38 millones de dólares. No salieron de un exchange descuidado ni de un smart contract con un bug de reentrancy de manual. Salieron de billeteras hardware que mucha gente del ecosistema trataba como el último bastión de la “autocustodia bien hecha”.

El fabricante es Coinkite. El producto, Coldcard. La fecha del reportaje que armó el ruido: 31 de julio de 2026, en CoinDesk. La historia no es de un genio rompiendo criptografía con un superordenador en un sótano. Es más prosaica y, por eso, más cabrona: ciertas versiones del firmware generaban semillas de recuperación con mucha menos aleatoriedad de la prevista. Menos entropía. Más predecible. Atacable por fuerza bruta hasta recrear la frase y vaciar la cartera.

Guy Swann lo resumió sin anestesia: lo calificó como “el peor golpe en la historia del bitcoin para los bitcoineros más entendidos y ‘adecuadamente asegurados’”. El matiz importa. No es el típico “le hackearon Binance y los normies lloran”. Es gente que hizo los deberes del catecismo maximalista, hardware wallet, seed offline, no confiar en custodios, y aun así se comió el marrón.

Eso no convierte a Coldcard en un ladrillo maldito para siempre. La falla se corrigió. Pero el daño ya estaba en las semillas nacidas bajo firmware vulnerable. Y ahí empieza la lección que de verdad duele.

Qué es una seed y por qué la aleatoriedad no es un detalle de frikis

Si nunca has tocado una hardware wallet, la analogía es simple. La “semilla” (seed phrase, frase de recuperación) es la llave maestra de tu caja fuerte. Suele ser una lista de palabras. Quien la tiene, manda sobre los fondos. El dispositivo hardware está pensado para generar esa llave en un entorno aislado, firmar transacciones sin exponer la clave privada a un PC infectado, y que tú duermas más o menos tranquilo.

Para que esa llave sea segura tiene que ser impredecible de verdad. En criptografía eso se llama entropía: la cantidad de azar real que metes en la generación. Si el generador de números “aleatorios” del firmware está cojo, porque lee mal el ruido del hardware, porque mezcla fuentes de forma defectuosa, porque un camino de código reduce el espacio de posibilidades, el resultado parece una seed normal… hasta que alguien descubre que el espacio de búsqueda es lo bastante pequeño como para recorrerlo.

No hace falta “hackear Coldcard en remoto” al estilo película. Basta con entender el fallo de generación, modelar cómo se acorta el azar, y probar combinaciones hasta dar con frases válidas que controlen monederos con saldo. CoinDesk recoge precisamente eso: investigadores vieron que ciertas versiones del firmware producían semillas con mucha menos aleatoriedad de la esperada, y eso las hacía susceptibles a ataques de fuerza bruta orientados a recrear las frases de recuperación.

Traducción de barra: te vendieron un dado de 100 caras. En la práctica, a veces salían números de un dado de 12. El resto es paciencia, hardware de cálculo y víctimas con pasta en direcciones derivadas de esas seeds.

Los números que sí constan (y los que no)

Lo que está sobre la mesa, según el artículo de CoinDesk del 31 de julio de 2026:

• El robo ronda casi 600 BTC, valorados en aproximadamente 38 millones de dólares.
• El vector: recreación de frases de recuperación a partir del fallo de firmware.
• El fabricante ha corregido la falla.
• Corregir el firmware no limpia el riesgo de las semillas ya generadas en versiones vulnerables: hay que mover fondos a carteras nuevas.
• NVK, CEO de Coinkite, pidió a quien generó una seed con Coldcard que transfiriera fondos de inmediato siguiendo las prácticas actualizadas.

Lo que no viene en el material y por tanto no vamos a inventar: versiones exactas de firmware afectadas, cuántas billeteras o usuarios pilló, el detalle milimétrico del exploit más allá de la entropía reducida, si el dinero es fácil de rastrear o recuperar, ni cuánto tiempo estuvo la vulnerabilidad expuesta antes de descubrirse.

Esa falta de granularidad es parte del problema informativo. “Casi 600” y “aproximadamente 38 millones” ya son una hostia. Convertirlo en cifra redonda de marketing (“exactamente 600 BTC / 38 M$”) solo sirve para sonar más seguro de lo que permite la fuente. Aquí nos quedamos con el margen.

También importa el marco: Blockaid, firma de seguridad blockchain citada en el mismo reportaje, señaló que en el primer semestre de 2026 la mayor parte de las pérdidas no vino de hackeos a contratos inteligentes, sino de claves comprometidas y fallos de seguridad operativa. Coldcard encaja en ese patrón. No es el drama del DeFi explotado por un reentrancy; es la capa aburrida y letal: la clave.

Actualizar no es migrar: la trampa psicológica del parche

Cuando sale un CVE de una app, actualizas y sigues. Con una seed generada en un dispositivo vulnerable, la lógica es otra. La seed ya existe. Vive en un papel, en una placa de metal, en la cabeza de alguien que la memorizó, y en la derivación de todas las direcciones que salieron de ella. El firmware nuevo puede generar bien las seeds futuras. No reescribe el pasado.

Por eso el mensaje operativo de Coinkite, vía NVK, no es “poned la última versión y a dormir”. Es: si generasteis la semilla en Coldcard (en el contexto del aviso), moved los fondos con las mejores prácticas actualizadas. Ya. Sin romanticismo.

Eso es un golpe de realismo para el discurso de “configúralo una vez y olvídate veinte años”. La autocustodia no es un cuadro que cuelgas en la pared. Es un sistema vivo: amenazas nuevas, bugs viejos que afloran, y decisiones de migración que no puedes delegar en un banner de “Update available”.

Udi Wertheimer, desarrollador de Taproot, lo formuló en la línea que muchos no quieren oír: la seguridad ya no es pasiva. O monitoreas amenazas de forma continua, o confías en custodios profesionales con equipos dedicados. No es un eslogan pro-banco. Es la descripción de un oficio que se ha vuelto dinámico. Quien vende “compra hardware, anota 24 palabras, fin de la historia” está vendiendo una foto de 2015 en un mundo de 2026.

Autocustodia: no ha muerto, pero el cuento del riesgo cero sí

Aquí es donde el debate se pone interesante y donde hay que separar dato de sermón.

Lorenzo Valente, director de investigación de activos digitales en ARK Invest, soltó una de las frases más honestas del ciclo: el espacio de hardware de autocustodia es un desastre, y los consumidores han cambiado el riesgo de contraparte (que te rugue el exchange) por un combo de riesgos de software, hardware, cadena de suministro, phishing y error humano.

Eso no es “la autocustodia es basura”. Es contabilidad de riesgos. Cambiaste “dependo de Coinbase/Kraken/Fondo X” por “dependo de que el RNG del firmware esté bien, de que el chip no esté implantado, de que el PDF de la seed no acabe en el correo, de que no te hagan un phishing de ‘actualiza tu wallet’, de que no te equivoques al copiar una transacción”. No has eliminado el riesgo. Lo has reubicado. A veces a un sitio mejor. A veces a un sitio que solo parece mejor porque lleva carcasa de acero y aura de cypherpunk.

Nick Neuman, CEO de Casa, cargó contra la recomendación de que la gente “tire dados” para reforzar la autocustodia: inviable para el 99% de las personas. Tiene razón en el diagnóstico de usabilidad aunque duela al purista. Un sistema de seguridad que solo funciona si eres un friki paciente con rituales de entropía manual no es un sistema de seguridad de masas. Es un club. Los clubs están bien. Confundir el club con la infraestructura por defecto del dinero del planeta es de iluso o de vendedor de cursos.

En el otro lado del tablero, observadores como David Lawrence (Amicus) apuntan a un efecto de segundo orden: este tipo de incidentes puede acelerar la adopción de custodios regulados y de ETFs de Bitcoin al contado, tipo el iShares Bitcoin Trust (IBIT) de BlackRock. No porque el ETF sea “más cypherpunk”. Porque para mucha gente el coste cognitivo y el riesgo operativo de la autocustodia acaban superando el miedo abstracto al custodio.

Seamos justos: la autocustodia bien ejecutada sigue siendo la única forma de eliminar el riesgo de contraparte y de censura transaccional. Para un perfil técnico que audita su propio stack, verifica firmas y rota seeds con disciplina, el control directo de las claves no tiene sustituto. El problema no es que el modelo sea inviable; es que se ha vendido como un producto de consumo cuando en realidad exige un oficio. Coldcard no invalida el principio de la autocustodia: demuestra que el firmware es parte del perímetro de seguridad, y que el open source sin verificación rigurosa no basta.

Lectura editorial, no dogma: el mercado no elige ideología; elige fricción percibida. Cada vez que un dispositivo de culto falla en la capa de confianza, sube el valor relativo del aburrido producto regulado con equipo de seguridad, seguros y horarios de oficina. Eso no cierra el debate. Lo reequilibra.

Open source no es un hechizo de protección

Andrew Lazutkin, CTO de Tangem, clavó otra verdad incómoda: que el firmware sea de código abierto no debe equipararse automáticamente con mayor seguridad. La seguridad sale de arquitectura sólida, pruebas exhaustivas y verificación independiente.

Esto debería ser obvio y no lo es. En software llevamos años viendo el mismo fetiche: “es open source, la comunidad lo audita”. La comunidad no audita un carajo de forma sistemática. Mira, a veces reporta. A veces un investigador se pone las gafas. El resto del tiempo el código abierto está ahí, público, y los bugs también, públicos en potencia, esperando a alguien con incentivo.

Un RNG mal cableado en el flujo de generación de seeds es exactamente el tipo de fallo que puede pasar desapercibido en una review superficial de “se ve limpio” y que solo aparece cuando alguien mide la distribución real de salidas, hace tests estadísticos, compara con el modelo de amenaza y pregunta: ¿cuántos bits de entropía efectiva estoy sacando de verdad, no en el README?

Open source ayuda a la verificabilidad. No sustituye la verificación. Si nadie mide la entropía, el repositorio de GitHub es decoración.

Dónde encaja la IA (sin vender magia)

El encargo de este texto no es solo crónicas del robo. Es preguntarse, con los pies en el suelo, qué podría haber aportado la IA para reducir las probabilidades de que un fallo así llegara a producción o se quedara años sin pillar.

Primero, lo que la IA no es: un amuleto que “asegura Coldcard” por el hecho de existir. Tampoco vamos a afirmar que “con IA no habría pasado”. Eso es humo de consultora. Lo que sí hay es un mapa de sitios donde modelos y herramientas automatizadas ya son útiles en ingeniería de seguridad, y donde un fallo de entropía es, en abstracto, un candidato de manual.

1. Revisión asistida del camino de entropía

Generar una seed no es un endpoint REST bonito. Es un pipeline: ruido de hardware → mezclas → KDF → codificación BIP-39 o similar → almacenamiento seguro. Un modelo de código bien usado no “entiende Bitcoin” como un humano senior, pero puede:

• Señalar funciones donde se trunca, se hace modulo de un rango mal elegido, o se reutiliza un buffer.
• Preguntar por fuentes de entropía no inicializadas o por caminos de error que caen a un PRNG débil.
• Exigir, en el propio PR, evidencia de tests estadísticos (chi-cuadrado, dieharder, NIST SP 800-22, lo que use el equipo) ligados a ese cambio.

No sustituye al criptógrafo. Multiplica la superficie de revisión barata antes de que el criptógrafo entre.

2. Fuzzing y tests diferenciales con ayuda de modelos

Los fallos de “menos aleatoriedad de la prevista” se cazan midiendo salidas, no leyendo comentarios en el código. Aquí la IA brilla menos como oráculo y más como copiloto de harness:

• Generar baterías de tests que fuerzan condiciones de borde en el RNG (temperatura, arranques en frío, falta de ruido, reintentos).
• Comparar distribuciones de seeds/símbolos entre versiones de firmware (“antes vs después”) y marcar colapsos de entropía.
• Priorizar mutaciones de input que exploren ramas raras del generador.

Si tu pipeline de release no tiene un canario que diga “esta build produce un espacio de seeds anómalamente pequeño”, estás volando a ciegas. La idea del canario barato antes de desplegar basura aplica igual de bien a un modelo de lenguaje que a un firmware que fabrica llaves maestras: una prueba automática mínima te salva de empujar basura con confianza alta.

3. Monitoreo de amenaza cuando el bug ya salió

Wertheimer tiene razón en el fondo: la seguridad pasiva se acabó. La IA, aquí, es aburrida y útil: clasificar avisos, cruzar indicadores de vaciado de wallets con patrones on-chain, alertar a equipos de soporte y a usuarios de alto patrimonio cuando un fabricante publica un advisory crítico.

Eso no recupera los casi 600 BTC. Reduce el tiempo entre “se publica el fallo” y “el usuario mueve fondos”. En incidentes de seed comprometida, el reloj es el producto.

4. Lo que no debes pedirle a un LLM

Que “audite el firmware y firme que está seguro”. Que invente un formal proof de un esquema que no ha modelado. Que sustituya a un lab externo con incentivo reputacional. Y, sobre todo, que te dé una falsa sensación de cierre porque el chat dijo “el código se ve bien”.

Si algo hemos aprendido de otros fallos de especificación en software serio es que el diablo está en los bordes del sistema, no en la demo feliz. Da igual que hablemos de agentes, de APIs o de billeteras: un fallo de alcance o de especificación no se arregla con postureo de “lo revisó la IA”.

Qué se puede copiar y qué te explota en la cara

Copiable (aunque no tengas un Coldcard)

• Tratar la generación de claves como superficie crítica con tests de entropía medibles, no como feature más del changelog.
• Asumir que un parche futuro no repara secretos ya emitidos. Plan de migración > plan de update.
• Separar “código visible” de “código verificado”. Exige terceros, recompensas, y mediciones.
• Contabilidad de riesgos honesta: autocustodia vs custodio vs ETF no es religión; es matriz de amenazas + capacidad operativa real.

Te explota en la cara si…

• Crees que “tengo hardware wallet” es sinónimo de “estoy fuera del alcance de fallos de software”.
• Generas la seed en un dispositivo y nunca vuelves a leer advisories del fabricante.
• Repites el mantra del open source como si fuera un pen-test continuo.
• Intentas el ritual de los dados y las ceremonias de entropía casera sin saber por qué, y acabas introduciendo peor azar o un error de transcripción. Neuman no exagera: el 99% no va a operar como un HSM humano.
• Lees “casi 38 millones” y concluyes “la autocustodia ha muerto”. El material no dice eso. Dice que duele, que hay debate, y que parte del capital puede irse al carril regulado. Convivencia tensa, no funeral.

El patrón de 2026: claves, no solo contratos

Blockaid encaja este incidente en una tendencia del primer semestre de 2026: las pérdidas grandes se concentran en claves comprometidas y fallos operativos más que en el mito del contrato inteligente “hackeado por un genio”.

Eso debería reordenar prioridades de quien construye producto cripto y de quien guarda patrimonio a largo plazo:

1. Key lifecycle, generación, backup, rotación, destrucción, herencia.
2. Supply chain del dispositivo, firmware firmado, verificable, con arranque medido donde aplique.
3. Operación humana, phishing, ingeniería social, falsas apps, “soporte” por DM.
4. Detección y respuesta, no solo prevención heroica.

Coldcard, en este episodio, no es “el villano de la autocustodia”. Es el ejemplo caro de que el eslabón criptográfico más romántico (la seed sagrada) sigue siendo software y hardware hechos por humanos. Los humanos meten bugs. Los bugs en RNG no se ven en la foto de producto.

Cierre sin moraleja de poster

Casi 600 BTC no se fueron por un eslogan. Se fueron por un fallo de generación de aleatoriedad en un dispositivo que mucha gente usaba precisamente para no fiarse de nadie. La falla se corrigió; las seeds viejas no se “curan” solas; el CEO pidió movimiento de fondos; el ecosistema discutió si el futuro es más custodio, más ETF, o autocustodia con menos fantasía y más ingeniería.

La IA no aparece en el comunicado como heroína del parche. Aparece, si acaso, en la conversación adulta de después: como lupa para revisar caminos de entropía, como músculo para tests y canarios, como radar cuando el advisory ya salió. Útil. Limitada. Mejor que el incienso del “not your keys, not your coins” repetido sin leer el advisory del mes.

Si tu plan de seguridad es merchandising, el próximo bug de firmware te va a costar más que una camiseta.

Preguntas frecuentes

¿Qué falló exactamente en Coldcard?

Según el reportaje de CoinDesk (31 de julio de 2026), ciertas versiones del firmware generaban semillas de recuperación con mucha menos aleatoriedad de la prevista. Eso permitió a atacantes recrear frases y vaciar billeteras. No se trata de un relato de hackeo a un exchange: el golpe fue a individuos que confiaban en hardware de autocustodia. La falla de firmware fue corregida después.

¿Sirve de algo actualizar el firmware si mi seed es antigua?

No elimina el riesgo de una semilla ya generada bajo firmware vulnerable. El aviso operativo va en otra dirección: transferir fondos a nuevas carteras con prácticas actualizadas. El firmware nuevo mejora el futuro; no reescribe una seed que ya existe en papel, metal o backup. NVK, CEO de Coinkite, instó a mover fondos a quien hubiera generado la seed con Coldcard.

¿Esto demuestra que la autocustodia ha muerto?

No. Demuestra que cambiar riesgo de contraparte por riesgos de software, hardware, cadena de suministro, phishing y error humano exige contabilidad honesta, no eslóganes. Hay voces (ARK Invest, Casa, Taproot, Amicus) que empujan el debate hacia más realismo operativo o hacia custodios y ETFs. El material presenta discusión, no un veredicto final de obituario.

¿El código abierto no debería haber evitado esto?

El código abierto facilita que otros miren. No garantiza que miren bien ni que midan entropía real. Como subrayó el CTO de Tangem en el debate recogido por CoinDesk, la seguridad depende de arquitectura sólida, pruebas exhaustivas y verificación independiente, no del badge de “open source” en la web del producto.