A finales de julio de 2026, el fabricante de hardware wallets Coinkite confirmó una falla en la generación de semillas de algunos modelos de Coldcard. Días después, el 7 de agosto, el proyecto BTCPay Server publicó un aviso crítico sobre una vulnerabilidad de software en su infraestructura de pagos, ya explotada activamente. El caso de Coldcard circuló primero en redes sociales —incluyendo una publicación muy compartida del desarrollador conocido como calle— antes de que existiera un aviso técnico completo, lo que produjo titulares alarmistas y cifras contradictorias. Este artículo contrasta esa publicación inicial y la cobertura de prensa con el aviso oficial de Coinkite y el análisis técnico independiente del equipo de ingeniería de Block; y, por separado, examina la alerta oficial de BTCPay Server y su aviso técnico en su blog. Cada incidente se presenta en su propia sección, sin mezclar sus causas técnicas, y se señala explícitamente en qué puntos las fuentes coinciden y en cuáles todavía no hay consenso.
Incidente 1: Coldcard — un problema de generación y entropía de semillas
Cómo se destapó el caso
El 30 de julio de 2026, usuarios reportaron movimientos de fondos no autorizados desde direcciones de Coldcard que llevaban años inactivas. Ese mismo día, calle publicó en X un mensaje describiendo la situación como «peor que cualquier hackeo previo a un exchange de Bitcoin» y afirmando que Block había confirmado que el generador de números aleatorios (RNG) estaba roto, además de sugerir que «el exploit fue descubierto muy probablemente con ayuda de IA». Por separado, el desarrollador independiente Alekos Filini publicó en X un análisis técnico propio sobre el commit que introdujo la librería libngu en el firmware de Coldcard. El equipo de Ingeniería y Seguridad de Bitcoin de Block publicó su propio reporte técnico ese mismo 30 de julio, indicando que había alertado a Coinkite de forma privada horas antes de la divulgación pública. Coinkite, por su parte, publicó un aviso preliminar reconociendo el problema en Coldcard Mk3 ese mismo día.
Es importante distinguir el origen de cada afirmación: la publicación de calle en X fue la que popularizó el caso, pero es una publicación de un tercero, no un aviso oficial ni un reporte técnico verificado en el momento en que se publicó. Su afirmación sobre el descubrimiento «con ayuda de IA» no aparece respaldada en el reporte técnico de Block, que atribuye el hallazgo a su propio equipo de ingeniería trabajando junto a «investigadores de seguridad anónimos». Tratamos esa afirmación específica como no confirmada.
La causa técnica raíz
Según el aviso de Coinkite y el análisis independiente de Block, el problema nació de un error de compilación en la librería libngu integrada en 2021: el código verificaba si una macro de activación del generador aleatorio por hardware estaba definida, en vez de verificar si estaba activada. El firmware terminó usando un generador por software de respaldo, inicializado con valores parcialmente predecibles (identificador del chip, contadores de tiempo), en lugar del generador aleatorio verdadero del chip STM32.
Cifras que aún no coinciden entre las fuentes
Hay coincidencia general entre estas fuentes sobre la naturaleza del problema, pero las cifras concretas todavía difieren según la fuente y siguieron cambiando mientras el incidente estaba en curso:
- Modelos y versiones: el aviso de Coinkite ubica el firmware vulnerable de Mk2/Mk3 entre las versiones 4.0.1 y 4.1.9, mientras que el análisis de Block señala como punto de partida la versión 4.0.0.
- Entropía perdida: Coinkite y varios medios (Bitcoin Well, Blockhead) hablan de ~40 bits efectivos en Mk2/Mk3 y ~72 bits en Mk4/Mk5/Q. El reporte de Block es más severo: habla de apenas ~2¹⁶ combinaciones en Mk2/Mk3 sin identificador de chip conocido, y de una función de re-siembra limitada a ~2³² combinaciones (32 bits, no 72) en Mk4/Mk5/Q. El propio Block aclara que «no se ha hecho una prueba empírica completa para confirmar la explotabilidad».
- Fondos afectados: las estimaciones subieron día a día: cerca de $38 millones el 30 de julio según Bitcoin.com News, ~$70 millones horas después según un análisis de Galaxy Research citado por The Hacker News, y cifras entre $114 y más de $130 millones citadas por CoinDesk, TRM Labs y TechCrunch entre el 3 y el 5 de agosto. Estas cifras provienen de firmas externas de analítica blockchain, no de un balance final de Coinkite.
Qué confirmó oficialmente Coinkite
Modelos afectados según el aviso vigente de Coinkite: Mk2/Mk3 con firmware 4.0.1–4.1.9; Mk4/Mk5 con firmware anterior a 5.6.0 (o 6.6.0X Edge); y Q con firmware anterior a 1.5.0Q (o 6.6.0QX Edge). TAPSIGNER, OPENDIME, SATSCARD y el Mk1 no están afectados. Las semillas generadas con al menos 50 tiradas de dados independientes, o protegidas con una passphrase BIP-39 fuerte, no se vieron comprometidas. Coinkite aclaró además que actualizar el firmware no repara una semilla ya generada con entropía débil: los fondos deben migrarse a una wallet completamente nueva.
Afirmaciones de terceros que Coinkite no ha confirmado
Además de la afirmación sobre un posible descubrimiento «asistido por IA», circula un señalamiento más serio: análisis de firmas GPG en commits de código abierto que vincularían la identidad de un integrante de Coinkite con una cuenta pseudónima que mantenía una de las librerías involucradas. CryptoTimes presentó esto explícitamente como una pregunta abierta, no como un hecho probado, y señala que Coinkite no ha respondido públicamente. La explicación oficial de Coinkite y de Block sigue siendo un error de compilación accidental de 2021, no un acto deliberado. No repetimos esa acusación como un hecho: es una especulación de prensa basada en evidencia circunstancial, no confirmada ni desmentida oficialmente.
Riesgo real y medidas oficiales recomendadas
El riesgo real solo aplica a wallets de una sola firma generadas en el dispositivo con firmware afectado, sin passphrase fuerte. Con base en el aviso oficial de Coinkite: instalar de inmediato el firmware corregido, generar una semilla completamente nueva, verificar el respaldo y las direcciones en pantalla, mover primero una cantidad pequeña de prueba, conservar el respaldo anterior hasta confirmar la migración, y no apresurar el proceso. Antes de mover fondos, cualquier propietario de Coldcard debería revisar el historial de divulgaciones de Coinkite para conocer el estado más reciente.
Cuatro conceptos que no debes confundir
Buena parte de la confusión pública viene de mezclar cuatro ideas relacionadas pero distintas:
A. Una semilla BIP-39 correctamente generada, con entropía suficiente. Creada a partir de una fuente de aleatoriedad genuina (128 o 256 bits) en la que, en la práctica, nadie puede reducir de forma significativa el número de combinaciones a adivinar.
B. Una semilla débil por una falla en el generador de números aleatorios (RNG). Es lo que ocurrió con Coldcard: el dispositivo creía usar su generador de hardware, pero usaba uno por software inicializado con valores parcialmente predecibles. El punto central de este caso: mantener el dispositivo desconectado de internet no protege los fondos si la semilla fue predecible desde el momento en que se creó. Los Coldcard afectados nunca se conectaron a internet, y aun así los fondos quedaron en riesgo.
C. Añadir dados a la generación interna de un dispositivo. Combinar tiradas de dados con la salida del generador interno (por ejemplo, con una operación XOR) es útil si la entropía externa es suficiente y la función de mezcla está bien implementada — no es una garantía automática.
D. Crear la entropía manualmente, siguiendo un procedimiento verificable. El método más auditable, porque no depende de ningún componente electrónico oculto: el propio usuario lanza dados físicos y sigue un algoritmo documentado, verificable paso a paso. Es el método que documenta el tutorial de Adrián Treviño que enlazamos más abajo, y es también uno de los métodos que Coinkite confirmó como no afectado.
Incidente 2: BTCPay Server — una vulnerabilidad de software e infraestructura de pagos
Este segundo caso no tiene relación técnica con el de Coldcard: no se trata de cómo se generó ninguna semilla, sino de una falla de software en un servidor de pagos que ya estaba operando.
Qué paso y cuándo
El 7 de agosto de 2026, BTCPay Server publicó, primero en su cuenta oficial de X y horas después en una entrada de blog oficial, un aviso crítico advirtiendo sobre una vulnerabilidad ya explotada activamente que podía provocar pérdida de fondos. El aviso pidió actualizar de inmediato a la versión 2.4.2 y verificar ese número en el pie del panel de administración. Para quienes no pudieran actualizar de inmediato, la recomendación fue apagar temporalmente el servidor.
Qué versiones y configuraciones fueron afectadas
Según el aviso oficial, todas las versiones anteriores a la 2.4.2 estaban expuestas. La vulnerabilidad permitía a un atacante remoto y sin autenticar obtener archivos de credenciales (.macaroon) usados por LND (Lightning Network Daemon). Las wallets on-chain integradas de BTCPay Server no se vieron directamente afectadas por esta vía, y las instalaciones sin LND enfrentan un riesgo menor.
Por qué las instalaciones con LND requerían atención especial
Un macaroon es una credencial que autoriza a un software a operar un nodo LND: controlarlo equivale a controlar los fondos del canal Lightning asociado. Al poder obtenerse ese archivo de forma remota y sin autenticación, un atacante no necesitaba robar contraseñas ni acceder físicamente al servidor. El aviso oficial fue explícito en que este riesgo «aplica específicamente a instalaciones que usan LND».
Qué hacer después de actualizar: rotación de credenciales y macaroons
En instalaciones estándar, el propio proceso de actualización a 2.4.2 regenera automáticamente las credenciales de LND. Esa regeneración solo cubre las rutas de acceso gestionadas directamente por BTCPay Server: si el nodo LND se expone también por un proxy inverso propio, un servicio Tor independiente o un puerto reenviado manualmente, esas credenciales deben rotarse por separado y de forma manual. Un análisis técnico independiente de TFTC recomienda además revocar el macaroon a nivel del propio nodo, invalidando la llave raíz de firma.
Riesgos que permanecen si un atacante accedió antes de actualizar
Actualizar a la 2.4.2 cierra la puerta a nuevos atacantes, pero no invalida por sí sola credenciales ya robadas de un servidor expuesto antes del parche. Como medida adicional, BTCPay Server restringió temporalmente el acceso remoto público a nodos LND en instalaciones Docker estándar mientras completaba la respuesta al incidente. Para más contexto sobre cómo evolucionó el caso, ver la cobertura de CoinDesk.
Cómo comprobar si una instalación pudo haber sido comprometida
El aviso oficial no ofrece una herramienta automática de detección; recomienda revisar manualmente: pagos no autorizados, cierres de canal inusuales, conexiones con pares (peers) no reconocidos, y discrepancias entre el saldo reportado y los registros propios. Ante cualquier duda razonable sobre exposición antes del 7 de agosto de 2026, la recomendación es tratar todas las credenciales asociadas como potencialmente comprometidas y rotarlas.
Dos incidentes distintos, una misma lección
El de Coldcard es un problema de generación y entropía de semillas: la falla ocurrió al crear la llave privada, antes de que existiera cualquier fondo asociado. El de BTCPay Server es una vulnerabilidad de software e infraestructura de pagos: la falla estaba en cómo el servidor exponía credenciales de un nodo Lightning ya en funcionamiento. Son causas técnicas completamente distintas, en capas distintas del sistema.
Lo que comparten no es la causa, sino la enseñanza: la autocustodia de bitcoin no es un evento único, sino un proceso continuo que exige mantenimiento (software y firmware siempre actualizados), verificación (comprobar direcciones, versiones y actividad) y separación de riesgos (no concentrar en un solo componente más valor del que necesita para cumplir su función).
Guía más amplia: cómo cuidar tus bitcoins
Si tu negocio usa BTCPay Server para aceptar pagos, la wallet conectada al servidor debe tratarse como una wallet caliente: un componente conectado a internet que no debería mantener más fondos de los necesarios para la operación diaria. Los ahorros —el bitcoin que no se necesita de forma inmediata— deben conservarse en una configuración de almacenamiento separada, idealmente en frí, transfiriendo periódicamente desde la wallet caliente. Esta separación no habría evitado la vulnerabilidad de BTCPay Server, pero sí habría limitado cuánto se podía perder a través de ella.
El incidente de Coldcard, por su parte, conecta directamente con la generación segura de semillas. Una hardware wallet es una herramienta, no una garantía: la seguridad depende de un conjunto de buenas prácticas que tú controlas.
1. Genera la semilla con suficiente entropía real
Confía en el generador aleatorio de tu dispositivo, pero recuerda que ningún componente está exento de errores de implementación. Complementar la generación con dados físicos o una passphrase fuerte añade una capa que no depende únicamente del dispositivo.
2. Nunca fotografíes, escanees ni digitalices tu semilla
Tu frase semilla nunca debe existir en formato digital. La única forma segura de respaldarla es en papel, metal o un medio físico equivalente, escrita a mano.
3. Mantén las palabras lejos de dispositivos conectados a internet
El proceso de generación y respaldo debe hacerse sin cámaras ni dispositivos conectados cerca. Como muestra este caso, la desconexión de red es necesaria, pero no suficiente por sí sola.
4. Verifica direcciones y respaldos
Verifica siempre las direcciones directamente en la pantalla de tu hardware wallet, y relee tu respaldo para confirmar que cada palabra está escrita correctamente y en el orden correcto.
5. Entiende bien una passphrase antes de utilizarla
Una passphrase añade entropía independiente del dispositivo, pero si la olvidas o la escribes mal, tus fondos son irrecuperables incluso con la semilla original intacta.
6. Prueba el proceso de recuperación antes de depositar montos importantes
Simula una recuperación completa con una cantidad pequeña de prueba. Descubrir un error en tu respaldo durante una prueba no cuesta nada; descubrirlo después de perder acceso puede costarte todo.
7. Mantén discreción sobre la existencia y ubicación de tus respaldos
Cuantas menos personas sepan que existe algo valioso que proteger y dónde buscarlo, menor es el riesgo de coerción o ingeniería social dirigida específicamente a ti.
8. Considera configuraciones más avanzadas, como multisig
Para montos importantes, una configuración multisig (por ejemplo, 2 de 3 firmas con dispositivos de distintos fabricantes) elimina el punto único de falla.
Recurso práctico: genera tu semilla BIP-39 lanzando dados
Como material de apoyo para entender en la práctica la generación manual y verificable de entropía, Adrián Treviño (@visionario_btc) publicó de forma gratuita la versión 3 de su tutorial «Genera tu semilla BIP-39 de Bitcoin lanzando dados», que ahora incluye una página dedicada a la passphrase: tutorial en español y tutorial en inglés.
Este recurso es una herramienta educativa para comprender y generar entropía con dados, no una solución automática ni un atajo casual —y tampoco es una respuesta a la vulnerabilidad de BTCPay Server. Generar tu semilla manualmente es un procedimiento avanzado: requiere seguir el método completo, usar dados físicamente equilibrados, respetar la cantidad de tiradas necesarias, y realizar todo el proceso sin cámaras ni dispositivos conectados cerca. No es apropiado para quien no pueda ejecutar y verificar correctamente todo el procedimiento de principio a fin. No se debe improvisar, atajar el conteo de tiradas ni inventar palabras.
Ningún método es infalible si no lo entiendes, lo verificas y lo ensayas
Ni el caso de Coldcard ni el de BTCPay Server señalan a una herramienta como «insegura» frente a otras: ambos recuerdan que cualquier dispositivo o software puede tener defectos que ni sus propios creadores detecten durante años. La defensa real es construir un proceso personal —y, si operas un negocio, también organizacional— de generación, respaldo, actualización, verificación y recuperación que entiendas a fondo y hayas puesto a prueba tú mismo. Autocustodia bien hecha significa exactamente eso: la responsabilidad, y el control, son tuyos.
Fuentes y lecturas recomendadas
1. Fuentes oficiales
- Coinkite Blog — Aviso: generación de semilla en Coldcard Mk3
- Coinkite — Historial de divulgaciones de seguridad
- Coldcard.com — Seguridad y verificación
- BTCPay Server (@BtcpayServer) en X — aviso inicial de la vulnerabilidad crítica
- BTCPay Server Blog — Aviso de seguridad: actualizar a 2.4.2 de inmediato
2. Análisis técnicos independientes
- Block Engineering Blog — RNG predecible y re-siembra de 32 bits en el firmware de Coldcard
- Alekos Filini (@afilini) en X — análisis del commit que introdujo libngu
- TFTC — BTCPay Server 2.4.2 corrige explotación de macaroon de LND
3. Cobertura y contexto
- calle (@callebtc) en X — publicación inicial que popularizó el caso Coldcard
- CoinDesk — Coldcard insta a usuarios a mover sus bitcoin mientras continúa el exploit
- The Hacker News — Falla de Coldcard vinculada a robo de $70 millones en 41 minutos
- Bitcoin.com News — Coinkite advierte a usuarios de Coldcard Mk3
- Bitcoin Well — Qué necesitan saber los usuarios sobre la vulnerabilidad de Coldcard
- Blockhead — Coldcard envió billeteras con aleatoriedad defectuosa durante cinco años
- TRM Labs — El mayor exploit de hardware wallet de 2026
- TechCrunch — Hackers roban más de $130M explotando un error en hardware wallets offline
- BleepingComputer — Falla de RNG en Coldcard posiblemente vinculada a robo de $88M
- CryptoTimes — Señalamiento (no confirmado) sobre un desarrollador de Coinkite
- Cointelegraph — BTCPay Server rota credenciales tras el exploit de Lightning
- CoinDesk — La semana de exploits en Bitcoin empeora: la falla de BTCPay drena nodos Lightning
4. Tutoriales y recursos prácticos
