Coldcard 5.6.1 ya está aquí: por qué la actualización no rescata tu semilla antigua

Coinkite distribuyó el 20 de agosto de 2026 los firmwares 5.6.1 para las Coldcard Mk4 y Mk5 y 1.5.1Q para el modelo Q. Si tienes una Coldcard, debes distinguir dos cosas. La actualización cierra el fallo para todo lo que crees a partir de ahora. No repara una semilla generada en una versión defectuosa. Para esa semilla, el único remedio es el traslado a una frase de recuperación recién generada.

El fabricante lo escribe de forma expresa en su comunicado: «Installing this update does not make an existing vulnerable seed safe.» En la página de estado, en la dirección coldcard.com/security/status, la fórmula es aún más breve: «An update is not a seed migration.»

Queda afectado, por tanto, quien configuró su dispositivo entre marzo de 2021 y julio de 2026 y desde entonces usa la misma frase de recuperación. En ese caso, la actualización por sí sola no basta, ni siquiera cuando la Coldcard muestra después el nuevo número de versión.

Coldcard 5.6.1 y 1.5.1Q: qué distribuyó el fabricante el 20 de agosto

Las dos versiones son fruto de una revisión de tres semanas que Coinkite había iniciado tras la actualización de emergencia del 31 de julio. Sustituyen a las versiones 5.6.0 y 1.5.0Q, lanzadas con premura entonces, y van más allá de la mera corrección de fallos.

La distribución se lee en el nombre del archivo. El archivo enlazado en la página de descargas para las Mk4 y Mk5 se llama 2026-08-20T1336-v5.6.1-mk-coldcard.dfu, y el del Q 2026-08-20T1335-v1.5.1Q-q1-coldcard.dfu. Ambos llevan, pues, el 20 de agosto como marca de tiempo en el propio nombre.

Según el fabricante, la versión abarca cuatro ámbitos: la generación de la semilla, la verificación de las transacciones antes de firmar, la separación de datos por la conexión USB y el comportamiento en las copias de seguridad. Coinkite antepone a esa enumeración una reserva de una sobriedad llamativa: se trata de controles concretos, no de la afirmación de que quede descartado todo fallo imaginable.

Una actualización de firmware no es una migración de semilla: por qué la semilla antigua sigue expuesta

La semilla es el número del que se derivan todas las claves y direcciones de una cartera; las doce o veinticuatro palabras de la hoja de emergencia no son más que su forma legible. Ese número se genera una sola vez, al configurar el dispositivo, y no se modifica nunca más.

De ahí procede justamente la peculiaridad de este caso. Una actualización de firmware sustituye el software que genera las semillas nuevas. No toca la semilla existente, porque no puede tocarla sin destruir la cartera. Así, quien actualiza un dispositivo afectado y luego lo sigue usando ha reparado el software y ha conservado la debilidad.

El propio incidente lo demostró durante el verano. Unos atacantes vaciaron saldos de bitcoin de dispositivos cuya frase de recuperación era predecible; describimos las primeras oleadas y la magnitud el 31 de julio en nuestro informe sobre el fallo del firmware de Coldcard. Las cifras de los daños totales difieren: TRM Labs los estima en unos 116 millones de dólares, mientras que CoinDesk cita unos 114 millones de dólares en su informe sobre el nuevo firmware. El relato de crypto.news habla de 1.816 bitcoins de más de 5.200 direcciones y observa que en torno al 90 % de los saldos sustraídos en las oleadas confirmadas aún no se han movido.

72 bits en lugar de 128: qué significa el fallo de entropía en la generación de la semilla

La entropía es la medida de cuántos valores distintos eran realmente posibles al generar una semilla; cuanto más alta, más inútil resulta el ensayo por fuerza bruta. El valor objetivo es de 128 bits.

No se alcanzó en las versiones afectadas. Según el fabricante, las semillas en Mk4, Mk5 y Q llegaban a unos 72 bits. Para los modelos más antiguos Mk2 y Mk3 la cifra comunicada es mucho más baja aún: crypto.news cita para ellos unos 40 bits de azar efectivo. La causa era la misma en ambos casos: los dispositivos tomaban el azar no del componente de hardware previsto para ello, sino de un sustituto por software.

Lo que esa diferencia significa en la práctica es difícil de captar en una sola imagen, porque la escala engaña. La distancia entre 72 y 128 bits no es un recargo, sino un desplazamiento de muchos órdenes de magnitud. Lo que cuenta para ti es la consecuencia llana: una semilla con demasiado poco azar es predecible, y lo sigue siendo mientras esté en uso.

Qué versiones se consideran afectadas

La guía de migración del fabricante nombra con precisión las versiones afectadas: las Mk2 y Mk3 con las versiones 4.0.1 a 4.1.9, las Mk4 y Mk5 en la rama estándar antes de 5.6.0, el Q antes de 1.5.0Q, las versiones Edge antes de 6.6.0X y 6.6.0QX respectivamente. El fallo se remonta así hasta marzo de 2021.

Entropía obligatoria para una semilla nueva: 65 pulsaciones, 50 tiradas de dado o 128 lanzamientos de moneda

El cambio más visible de la nueva versión afecta a la configuración. En la rama estándar, una semilla nueva ya no nace solo del azar del dispositivo. Debes aportar tú mismo azar, mediante exactamente uno de tres métodos: al menos 65 pulsaciones a un ritmo imprevisible, 50 tiradas de un dado real de seis caras o 128 lanzamientos de moneda.

El dispositivo mezcla esa parte que tú generas con azar fresco del dispositivo. Según el archivo de estado legible por máquina del fabricante, la aportación de ambos componentes de seguridad entra en cada semilla. Quien quiera evitar por completo el azar del dispositivo encontrará para ello la rama aparte «Dice Rolls Only»: exige 50 tiradas para una frase de doce palabras y 99 tiradas para una de veinticuatro.

El esfuerzo es intencionado. Traslada una parte de la confianza del componente de vuelta a ti, y es el punto en el que configurar una cartera de hardware se siente ahora notablemente distinto que antes. Si puedes elegir, opta por el método del dado: es el más fácil de seguir y puede observarse como un proceso en sí mismo.

Nuestro propio recuento: qué firmware de Coldcard ofrecía el fabricante el 22 de agosto

cryptoticker.io realizó este recuento por su cuenta el 22 de agosto de 2026. Método: consulta de la página pública de descargas del fabricante en coldcard.com/downloads con un identificador de navegador, seguida del recuento de cada fila de modelo allí listada, con número de versión y marca. Se comprobaron siete filas de modelos.

El resultado: cinco de las siete filas llevan la nota «Fixed release», dos no. Marcadas están las filas Mk5/Mk4 con 5.6.1, el Q con 1.5.1Q, las ramas Edge con 6.6.0X y 6.6.0QX, así como la fila común a Mk3 y Mk2 con 4.2.0. Quedan sin la nota dos filas que la propia página da por superadas: una fila Mk4 independiente con la versión 5.4.5 y la fila Mk1 con 3.0.6.

Para los propietarios de Mk1 ese es el hallazgo prácticamente relevante. El aviso de seguridad nombra 4.0.1 como primera versión afectada, mientras que la línea Mk1 termina en 3.0.6 y no muestra ninguna versión corregida. Qué se deduce de ello para una Mk1, la página no lo dice de forma expresa.

Un segundo hallazgo afecta a la fecha de verificación. La página de estado lleva el sello «Verified 2026-08-17» y recomienda al mismo tiempo 5.6.1 y 1.5.1Q, dos versiones distribuidas solo tres días más tarde. Si la página se verificó de nuevo tras la distribución y solo no se actualizó el sello, eso no se desprende de ella.

Una breve comprobación adicional atendió al idioma: se consultaron tres rutas alemanas de las direcciones del fabricante, y las tres respondieron con un 404. El aviso de seguridad, la página de estado y la guía de migración solo existen en inglés.

Los límites de este recuento

Lo que no pudo comprobarse es si la fila Mk4 dada por superada, con 5.4.5, contiene el fallo o solo documenta una rama descontinuada. Tampoco es verificable cuántos dispositivos hay afectados en Alemania, cuántos titulares han instalado ya la actualización y si el fabricante informa a sus clientes por correo en alemán. El recuento solo dice lo que la página de descargas mostraba ese día.

La rama de versión en lugar del nombre del modelo: qué versión mínima rige para tu dispositivo

Una rama de versión es el canal de distribución en el que se mantiene un firmware; un mismo dispositivo puede llevar números de versión completamente distintos según la rama. Justo ahí fracasan las comprobaciones que se guían solo por el nombre del modelo.

Por eso el fabricante nombra versiones mínimas por rama. Para las Mk2 y Mk3 rige 4.2.0 o más reciente. Para las Mk4 y Mk5 en la rama estándar rige 5.6.0 o más reciente; para el Q en la rama estándar, 1.5.0Q o más reciente. Quien vaya por la rama Edge necesita 6.6.0X en las Mk4 y Mk5, o 6.6.0QX en el Q. Como versiones actualmente recomendadas cita además 5.6.1 y 1.5.1Q.

En la práctica eso significa: abre en el dispositivo la pantalla de la versión del firmware, anótala por completo, sufijo de letra incluido, y compárala con la versión mínima de tu rama. Una «X» o «QX» al final apunta a la rama Edge, para la que rigen otras cifras.

La excepción del dado: cuándo una semilla existente no debe migrarse, según el fabricante

Hay un caso en el que el fabricante considera prescindible el traslado. Quien enriqueció su semilla en su momento con tiradas propias, mediante la función «Add Dice Rolls», puede, bajo condiciones estrictas, ahorrárselo.

Las condiciones están fijadas con precisión en la guía: al menos 50 tiradas limpias y mutuamente independientes, introducidas por esa función; la secuencia de tiradas debe haber permanecido privada y no haberse anotado ni revelado nunca; y las palabras que hay que usar son las que el dispositivo mostró tras añadir las tiradas. Bajo esas condiciones, el fabricante da por aportados al menos 128 bits de entropía adicional; a partir de 99 tiradas cita unos 256 bits.

La frase que importa llega al final: con menos tiradas o en condiciones inciertas, hay que migrar. Quien, tras cuatro años, ya no recuerde con claridad cuántas tiradas hubo y si la secuencia realmente no se anotó en ningún sitio queda sujeto a la obligación de migrar. Aquí la incertidumbre no cuenta como descargo.

Comprobación PSBT y SIGHASH_SINGLE: qué fallos más allá de la generación de la semilla se corrigieron

La revisión de tres semanas sacó a la luz puntos que nada tienen que ver con el fallo de azar original. Afectan al trayecto que un envío recorre del ordenador al dispositivo y de vuelta.

Una PSBT es una transacción de bitcoin parcialmente firmada: el archivo en el que el software de cartera deposita la propuesta de pago y que a la cartera de hardware se le muestra para su aprobación. La novedad es que la Coldcard vuelve a comprobar ese archivo justo antes de firmar e interrumpe la operación con el mensaje «Transaction modified» si algo ha cambiado entre la visualización y la aprobación. En la entrega por USB, la suma de verificación de la petición debe coincidir además con el archivo guardado, o la operación termina con «PSBT checksum mismatch».

SIGHASH_SINGLE es una variante de firma que solo fija una parte de una transacción y deja el resto abierto. En adelante se bloqueará por defecto. A ello se suman límites más estrictos en la recuperación de datos por USB, ceñida al resultado de la sesión cifrada en curso, así como la exigencia de que un archivo de firmware coincida con su longitud firmada.

Otros cambios afectan a la comprobación según BIP-322, al aislamiento del modo delta y al comportamiento en las copias de seguridad: una copia capta la cartera vigente en ese momento. En el caso de una cartera con frase de contraseña contiene la clave maestra derivada de esa cartera, no las palabras de la semilla matriz ni la frase de contraseña.

La frase de contraseña BIP-39: por qué no repara una semilla afectada

Una frase de contraseña BIP-39 es una palabra o frase adicional, de libre elección, de la que, junto con la semilla, nace una cartera propia. Con razón pasa por una salvaguarda adicional sólida, y el fabricante la recomienda de forma expresa para toda cartera cuya pérdida le doliera de veras a su propietario.

Para el fallo presente, sin embargo, no resuelve el problema. El fabricante lo formula sin equívocos: una frase de contraseña fuerte y única puede dificultar el acceso a la semilla subyacente, pero no la repara. Los usuarios con frase de contraseña deberían migrar tan pronto como sea factible.

Quien emplee una frase de contraseña para una cartera nueva debería respaldarla por separado de la semilla, anotar la huella de la cartera con frase de contraseña y probar la recuperación antes de que llegue dinero alguno. Qué «duele de veras», el fabricante no lo fija a propósito como importe; es un umbral personal.

Comprobar el archivo de firmware: suma de verificación SHA-256 y firma antes de instalar

Un incidente de seguridad atrae a los imitadores, y un archivo de firmware falsificado sería el camino más cómodo hacia los saldos ajenos. Por eso el fabricante exige dos comprobaciones antes de que el archivo llegue a la tarjeta de memoria.

Primero, el cotejo de la suma de verificación SHA-256: una suma de verificación es una breve huella de un archivo que cambia por completo ante la más mínima alteración. Segundo, el control del archivo firmado signatures.txt, que acredita que el archivo procede realmente del fabricante. Solo después viene la instalación por la tarjeta de memoria y, tras el reinicio, la comprobación visual del número de versión mostrado.

Descarga el archivo únicamente de la dirección del fabricante y nunca de un foro, un chat o un enlace que alguien te haya enviado sin pedirlo. Y una regla básica que la guía de migración repite de forma expresa: no introduzcas nunca tus palabras de semilla en un sitio web ni las envíes nunca a un canal de asistencia.

Migración de la semilla paso a paso: cómo transcurre el traslado a la nueva cartera

El fabricante describe dos vías. La recomendada pasa por dos dispositivos, porque en ningún momento se abandona una cartera en funcionamiento.

Si para esta vía tienes que adquirir un segundo dispositivo, encontrarás los modelos disponibles y sus diferencias en nuestra comparativa de carteras de hardware. No es obligatorio un dispositivo del mismo fabricante: una frase de recuperación según la norma BIP-39 puede, en principio, cargarse también en un dispositivo de otra marca.

En el segundo dispositivo se instala el firmware corregido y se genera una semilla enteramente nueva, expresamente no un clon de la antigua. Después se comprueban la copia de seguridad y la huella de la nueva cartera. Sigue un pequeño envío de prueba de la cartera antigua a la nueva y, solo una vez que ha llegado, va el resto detrás. La copia antigua se conserva hasta que el traslado quede concluido.

Quien solo tenga un dispositivo va por la vía de reserva: comprobar primero la copia de seguridad y la huella de la semilla antigua, instalar luego el firmware corregido, borrar la semilla antigua en el dispositivo, generar y comprobar la nueva, y transferir los saldos cargando de forma alterna ambas semillas. Esta vía es más delicada, porque durante un tiempo prescinde de una segunda salvaguarda.

La guía destaca tres advertencias de forma expresa. No destruyas nunca la única copia en funcionamiento de una cartera. Interrumpe y no transfieras nada si una huella o una dirección no coinciden. Y no uses las funciones de clonado o de traspaso del dispositivo como solución: copian la semilla afectada con todo lo demás.

Qué deberías documentar durante el traslado

El traslado da lugar a movimientos entre tus propias direcciones. De cada uno, anota la hora, el identificador de transacción y las direcciones implicadas, y guarda la nota junto con el resto de tus documentos. Cuesta cinco minutos durante el traslado y te ahorra después la reconstrucción de memoria, cuando haya que acreditar el recorrido de tus saldos.

Comprobaciones independientes y post mortem abierto: qué no está aún acreditado

Coinkite enumera cuatro comprobaciones externas en su página de estado, cada una con nombre, objeto y alcance. Un revisor con la cuenta @bigshiny0 midió en un dispositivo real con firmware Mk4 5.6.0 que una petición de 32 bytes desencadena ocho operaciones de lectura en el generador de números aleatorios por hardware: la vía corregida alcanza, pues, el componente. Un segundo revisor leyó el código fuente en todas las ramas corregidas y confirmó que el sustituto por software se había retirado. Un tercero comprobó lo mismo para la actualización de emergencia. Un cuarto reconstruyó la versión 5.6.0 y la comparó byte a byte con el archivo firmado publicado.

El fabricante matiza él mismo estas pruebas. Los elementos publicados no constituyen una auditoría independiente completa de cada archivo de firmware corregido; cada uno confirma solo su propio alcance de revisión. Llama además la atención que las comprobaciones citadas se refieran a 5.6.0, mientras que 5.6.1 es la versión actualmente recomendada.

El balance también queda abierto. A la pregunta de si el post mortem técnico formal está disponible, la página de estado responde, a fecha de 15 de agosto de 2026: no, sigue en curso. Quien quiera saber cómo pudo pasar inadvertido el fallo durante cuatro años sigue, por tanto, esperando.

Una valoración, señalada como tal: que un fabricante nombre con tanta claridad los límites de sus propias pruebas es inusual y habla a favor de su exposición. No sustituye, sin embargo, al informe pendiente, y para la pregunta de si sigues confiando en tu dispositivo, el post mortem sigue siendo el texto más importante.

Comprobar el firmware de tu Coldcard: qué te llevas de aquí

1. Comprueba primero el número de versión en el dispositivo, no el modelo. Anota la versión completa, sufijo de letra incluido, y compárala con la versión mínima de tu rama: 4.2.0 para las Mk2 y Mk3, 5.6.0 para las Mk4 y Mk5 en la rama estándar, 1.5.0Q para el Q, 6.6.0X o 6.6.0QX en la rama Edge. Si tu versión está por debajo, descarga la versión corregida de la dirección del fabricante, coteja la suma de verificación y la firma, e instálala. Si de todos modos estás pensando en tu dispositivo, nuestra comparativa de carteras de hardware te ayuda a sopesar los modelos.
2. Decide después por separado sobre la semilla. Si tu frase de recuperación se generó entre marzo de 2021 y julio de 2026 en una versión afectada, genera una semilla nueva y traslada tus saldos, preferiblemente por la vía de dos dispositivos y con un pequeño envío de prueba de antemano. Solo la estrecha excepción del dado, con al menos 50 tiradas privadas e independientes, te exime de ello. Si aprovechas el traslado para reordenar tu reparto, la comparativa de carteras de software reúne las contrapartes para el uso diario.
3. Documenta el traslado mientras transcurre. Anota la hora, el identificador de transacción y las direcciones de cada movimiento; después es laborioso. Un seguidor de cartera te libera en gran medida de esa contabilidad, y un resumen de los programas habituales figura en nuestra comparativa de herramientas fiscales de cripto y seguidores de cartera.

Encontrarás el comunicado del fabricante sobre la versión en el blog de Coinkite sobre las versiones 5.6.1 y 1.5.1Q, y las instrucciones paso a paso del traslado en la guía de migración de Coldcard.

(23 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)