Seguridad de billeteras hardware tras el exploit de Coldcard: opciones de custodia explicadas (2026)

Entre el 30 de julio y principios de agosto de 2026, se drenaron bitcoins de miles de direcciones que estaban almacenadas en billeteras hardware, los dispositivos que la gente compra específicamente para evitar ese resultado. La causa fue una falla de firmware en las billeteras Coldcard, fabricadas por Coinkite. Hay tres cosas que vale la pena aclarar de entrada: la falla ha sido parcheada, las versiones afectadas son un conjunto limitado e identificable en lugar de cada dispositivo vendido, y los usuarios que habían añadido una frase de contraseña (passphrase) a su semilla estaban en un riesgo significativamente menor. Lo que sigue es lo que sucedió, quién estuvo expuesto, qué se les está diciendo a los usuarios afectados y cómo se comparan las principales opciones de custodia una vez que se nombra el modo de falla de cada lado.

Qué sucedió: una cronología fechada

Las pérdidas reportadas escalaron en oleadas. Deben leerse como una secuencia de cifras fechadas, no colapsadas en un solo número de titular.

• 30 de julio de 2026 — la primera oleada. Aproximadamente 594 BTC (unos 38 millones de dólares) fueron drenados de unas 500 direcciones inactivas en menos de una hora.
• Alrededor de 30 horas — cuánto tiempo duró el ataque antes de la divulgación pública de Coinkite.
• 31 de julio de 2026 — los fondos aún no habían sido liquidados. Paul Howard de Wincent, hablando con CoinDesk, dijo que la probabilidad de liquidación "pesará sobre el precio de bitcoin a corto plazo".
• 1 de agosto de 2026 — Coinkite había emitido un aviso y enviado firmware parcheado.
• Principios de agosto de 2026 — el total acumulado reportado a través de varias oleadas alcanzó aproximadamente 1,367 BTC (unos 88–89 millones de dólares) en 4,585 direcciones. Algunos informes lo sitúan más alto.

Cómo funcionó la falla

La promesa central de una billetera hardware es que la clave privada se crea en el dispositivo y nunca lo abandona. Esa promesa descansa en una cosa: la semilla de la que se deriva la clave debe ser genuinamente impredecible.

En el firmware afectado, la generación de semillas no recurrió al generador de números aleatorios por hardware del chip STM32. Recurrió a un generador de software determinista: el respaldo Yasmarang de MicroPython. Determinista es la palabra operativa: las mismas condiciones iniciales producen el mismo resultado cada vez, por lo que el conjunto de semillas posibles se reduce de astronómicamente grande a algo que un atacante puede procesar sin conexión y verificar contra la cadena de bloques pública.

Es por eso que este exploit no requirió acceso físico al dispositivo de nadie. Nada fue robado, abierto o manipulado. Las claves fueron reconstruidas mediante computación y las direcciones que controlaban fueron vaciadas.

Quién fue afectado — y quién no

La exposición está limitada a firmware identificable: Coldcard Mk3 v4.0.1–4.1.9 y anteriores, rastreable hasta una compilación de marzo de 2021. La versión que importa es bajo la cual se generó la semilla, no la versión instalada actualmente; un dispositivo actualizado muchas veces desde entonces aún puede estar manteniendo una semilla creada en una compilación afectada.

Dos cosas protegieron a los usuarios. Las semillas complementadas con entropía independiente, como los lanzamientos de dados mezclados en la generación, están en un riesgo significativamente menor. También lo están las semillas protegidas por una frase de contraseña BIP-39 fuerte. La frase de contraseña es el detalle concreto y poco cubierto en la mayoría de la cobertura de este evento: es un secreto adicional que se coloca sobre la semilla y nunca se escribe en la copia de seguridad del dispositivo, por lo que recuperar la semilla sola no reconstruye la billetera. También es la configuración que la mayoría de los propietarios omiten, porque añade una segunda cosa que perder.

Qué deben hacer los usuarios afectados

El aviso de Coinkite es directo: si la semilla se generó en una versión afectada, migre los fondos.

1. Establezca bajo qué compilación de firmware se creó la semilla, no solo lo que el dispositivo ejecuta hoy.
2. Instale el firmware parcheado lanzado antes del 1 de agosto de 2026.
3. Genere una semilla completamente nueva y mueva los fondos a ella. Parchear solo no repara una semilla débil existente; esa clave ya existe y aún puede derivarse.
4. Trate las direcciones antiguas como comprometidas y deje de recibir fondos en ellas, incluso si nada se ha movido todavía.

La custodia es un espectro, no un binario

El marco útil aquí no es "autocustodia versus exchanges". Es un espectro de compensaciones, donde cada posición tiene un modo de falla nombrado y ninguna tiene cero.

Billetera hardware con frase de contraseña

La posición más fuerte contra esta clase específica de ataque: una semilla comprometida no es suficiente por sí sola. El modo de falla es humano, no técnico: una frase de contraseña olvidada o mal respaldada hace que los fondos sean permanentemente irrecuperables, sin ruta de recuperación y sin nadie a quien apelar.

Billetera hardware sola

Ninguna contraparte tiene nada, y ninguna falla de la empresa puede tocar los fondos. El modo de falla es el firmware y la cadena de suministro: precisamente este evento. El usuario también es responsable de las actualizaciones, copias de seguridad y migraciones, y este exploit mostró que la responsabilidad incluye actuar rápidamente ante un aviso.

Custodia en exchange

El problema de la semilla desaparece porque el usuario nunca genera una. El modo de falla se mueve al riesgo de contraparte, y el caso de referencia es FTX: activos de clientes depositados en un custodio que falló. Los traders que mantienen un saldo operativo en una plataforma — ya sea que estén comprando bitcoin o negociando futuros — han cambiado el riesgo de gestión de claves por riesgo de contraparte, no eliminado el riesgo.

El argumento sobre qué compensación es mejor está genuinamente abierto. CoinDesk informó el 2 de agosto de 2026 que, a diferencia del colapso de FTX, este exploit tiene a inversores enviando bitcoin de vuelta a los exchanges. Eric Balchunas de Bloomberg argumentó que fortalece el caso para los ETFs de bitcoin al contado, que sacan al usuario de la creación de semillas, actualizaciones de firmware, copias de seguridad y migración por completo. Willy Woo defendió públicamente la autocustodia (CryptoTimes, 3 de agosto de 2026). Ambos describen una compensación real, y este evento no la resolvió.

Preguntas frecuentes

¿Cómo sé si mi Coldcard está afectado?

El conjunto afectado es el firmware Coldcard Mk3 v4.0.1–4.1.9 y anteriores, rastreable hasta una compilación de marzo de 2021. El factor determinante es la versión de firmware presente cuando se generó la semilla. El aviso de Coinkite es la referencia autorizada para verificar un dispositivo específico.

¿Actualizar el firmware protege los fondos que ya están en mi billetera?

No. El parche corrige cómo se generan las nuevas semillas. Una semilla creada en una compilación afectada permanece débil después de la actualización, por lo que el aviso pide a los usuarios que migren a una billetera con una semilla recién generada en lugar de simplemente actualizar.

¿Hizo alguna diferencia la frase de contraseña?

Sí. Las semillas protegidas por una frase de contraseña BIP-39 fuerte, o complementadas con entropía independiente como lanzamientos de dados, están en un riesgo significativamente menor. Sigue siendo una compensación en lugar de una actualización gratuita: una frase de contraseña irrecuperable es una billetera irrecuperable.

Este artículo es solo para fines informativos y no constituye asesoramiento de inversión.