Las carteras de hardware se construyen sobre una promesa sencilla: mantener las claves fuera de línea para que los atacantes no puedan alcanzarlas.
El hackeo de Coldcard rompió esa suposición.
Un fallo hizo que algunas frases de recuperación fueran predecibles desde el momento de su creación, lo que permitió robar Bitcoin mientras las carteras seguían fuera de línea y protegidas físicamente.
Esta semana analizamos cómo el incidente sacudió la confianza en la autocustodia de Bitcoin y empujó a algunos titulares de vuelta hacia los exchanges. Después examinamos el fallo técnico que hizo predecibles las claves y por qué actualizar una cartera afectada no puede proteger claves que ya se habían creado.
También en este número: un gusano de npm que se propaga solo, un día cero de Metabase, una omisión en Screen Sharing de macOS, una vulnerabilidad explotada en LoadMaster, routers con backdoor, LLVM para pruebas de seguridad, un sospechoso correo de renovación de SSO de GitHub y más.
En este número
🌡️ Nivel de amenaza: Alerta alta
⚡ Noticias: Cinco noticias de seguridad que conviene conocer
🔎 Análisis a fondo: Cómo el hackeo de Coldcard sacudió la confianza en la autocustodia de Bitcoin
🎣 ¿Es phishing?
🔬 Investigación técnica: La cartera siguió fuera de línea. El atacante encontró la clave de todos modos.
🛠️ Herramienta de la semana: LLVM
👤 Persona de la semana: Andrea Fioraldi
📅 Evento de la semana: Ekoparty Security Conference 2026
📚 Libro de la semana: Black Hat GraphQL
😅 El meme
❓ Una pregunta antes de despedirnos
Manos a la obra.
Antes de entrar en las historias de esta semana, este es el estado del nivel de amenaza.
🌡️ Nivel de amenaza
⚡ Noticias
Más de 400 paquetes de npm se convirtieron en un gusano que se propaga solo
ChainDrop infectó paquetes populares de JavaScript mediante credenciales de publicación robadas. El malware se ejecutaba durante la instalación, buscaba en las estaciones de trabajo de los desarrolladores y en los sistemas de CI/CD secretos de npm, GitHub, la nube y la infraestructura, y luego usaba los tokens robados para infectar más paquetes de forma automática. Microsoft identificó más de 400 paquetes afectados. Unit 42 encontró 453 repositorios públicos de GitHub que coincidían con los patrones de robo de datos del gusano y observó su ejecución en diez entornos.
Los tokens robados infectan sistemas de desarrolladores y de CI.
Un día cero de Metabase convirtió el restablecimiento de contraseña en acceso de administrador
Metabase confirmó que los atacantes explotaron una vulnerabilidad de inyección SQL desconocida hasta entonces contra su servicio en la nube. El endpoint vulnerable de restablecimiento de contraseña permitía a atacantes remotos sin credenciales obtener acceso de administrador, lo que podía exponer las credenciales y los datos de las bases de datos conectadas. Metabase aplicó el parche en su plataforma en la nube y publicó correcciones para las versiones autoalojadas. Framework, Tally y Kilo Code informaron después de una exposición que afectaba a información de contacto de clientes, hashes de contraseñas o tokens de acceso a Slack.
La omisión del restablecimiento de contraseña expone bases de datos conectadas.
No hace falta una contraseña válida: Apple corrige una omisión en Screen Sharing de macOS
Apple divulgó que un atacante en la misma red podía autenticarse en Screen Sharing de macOS sin credenciales válidas. La vulnerabilidad, identificada como CVE-2026-65400, funcionaba antes de la autenticación y afectaba a los sistemas con Screen Sharing habilitado. Huntress descubrió que cambiar la contraseña de VNC o restringir los usuarios permitidos no impedía la explotación. Apple corrigió el fallo el 6 de agosto en macOS Tahoe 26.6.1, Sequoia 15.7.9 y Sonoma 14.8.9.
Un atacante local omite la autenticación de Screen Sharing.
CISA dio a las agencias tres días para corregir una vulnerabilidad explotada de LoadMaster
CVE-2026-8037 afecta a Progress Kemp LoadMaster, un producto que distribuye el tráfico entre aplicaciones y servidores. La vulnerabilidad permite a un atacante remoto sin credenciales ejecutar comandos del sistema operativo mediante datos de entrada insuficientemente comprobados que se envían al dispositivo. Progress publicó correcciones para las versiones afectadas. CISA añadió la vulnerabilidad a su catálogo de Vulnerabilidades Explotadas Conocidas el 7 de agosto y fijó el 10 de agosto como plazo de corrección para las agencias federales.
Una solicitud no autenticada explota un balanceador de carga vulnerable.
Más de 20 modelos de router se comercializaron con un backdoor de nivel root activado por defecto
VulnCheck encontró un implante de control remoto llamado ENDLESSDOORS dentro de routers vendidos con las marcas Zbtlink y Wiflyer. El software contacta con infraestructura externa y puede ejecutar comandos con todos los privilegios del sistema sin autenticar al servidor. VulnCheck estima que podría haber desplegados en todo el mundo al menos 100,000 routers afectados. El 6 de agosto, Zbtlink afirmó que el implante era una herramienta de soporte, suspendió la venta de los routers afectados, retiró el firmware y empezó a desarrollar actualizaciones.
Un implante integrado permite el control remoto del router.
🔎 Análisis a fondo
Cómo el hackeo de Coldcard sacudió la confianza en la autocustodia de Bitcoin
Los hackers robaron alrededor de 130 millones de dólares en Bitcoin de carteras de hardware Coldcard, lo que lo convierte en el tercer mayor hackeo de criptomonedas de 2026.
Las carteras de hardware se construyen sobre una promesa sencilla: mantener las claves fuera de línea para que los atacantes remotos no puedan alcanzarlas. No hay ninguna cuenta que comprometer, ningún servidor que guarde el secreto y ninguna forma de entrar sin la frase de recuperación o el dispositivo físico.
El robo de Coldcard rompió esa promesa.
Las carteras siguieron fuera de línea, pero el Bitcoin se robó igualmente. Quedó expuesta una debilidad en una de las principales herramientas en las que se apoya la autocustodia de Bitcoin.
Autocustodia significa tener las claves de su propio Bitcoin en lugar de dejar ese control en manos de un exchange o de otra empresa. Las carteras de hardware crean y almacenan esas claves fuera de línea, donde se supone que permanecen fuera del alcance de los atacantes en línea.
Coldcard era una cartera de hardware solo para Bitcoin, consolidada y con una sólida reputación de seguridad. Sin embargo, un fallo en la forma en que algunos dispositivos generaban las frases de recuperación hacía predecibles sus claves desde el momento en que se creaban. Los atacantes podían reconstruir esas claves y acceder a los fondos sin vulnerar las protecciones físicas de las carteras.
Así que la verdadera pregunta es:
¿Qué ocurre cuando el dispositivo destinado a proteger la autocustodia se convierte en su eslabón más débil?
La autocustodia elimina al custodio, no la confianza
Las personas eligen la autocustodia para no tener que confiar su Bitcoin a un exchange o a una institución financiera. Pero controlar las claves privadas también implica protegerlas de forma segura.
Antes de las carteras de hardware, esto solía exigir carteras de papel o equipos mantenidos permanentemente fuera de línea. Las carteras de hardware convirtieron esas configuraciones complicadas en un dispositivo dedicado que creaba las claves y las mantenía fuera de línea.
Esto hizo práctica la autocustodia, pero no eliminó la confianza. La trasladó de la institución que custodiaba el Bitcoin al fabricante que construía la cartera.
La mayoría de los usuarios no puede verificar cómo su dispositivo crea sus claves. Tienen que confiar en que el fabricante resolvió correctamente la parte más importante.
El hackeo de Coldcard hizo que los usuarios cuestionaran la autocustodia
Coldcard era una de las pocas carteras de hardware consolidadas solo para Bitcoin. Se había convertido en una opción de confianza entre quienes querían mantener sus claves de Bitcoin fuera de línea y fuera de un exchange.
Esa reputación hizo más significativo el hackeo.
La función de Coldcard no era simplemente mantener esas claves fuera de línea. Los usuarios confiaban en que las creara de forma segura desde el principio. Si ese paso fallaba sin que el propietario lo supiera, todas las protecciones posteriores se construían en torno a una clave vulnerable.
Una víctima informó a Galaxy Research de que su Coldcard había permanecido dentro de una caja de seguridad de un banco y nunca se había conectado a internet. Aun así, los atacantes robaron 18.25 BTC en siete minutos. El dispositivo había permanecido protegido físicamente, pero la clave que creó no.
El riesgo provenía del producto que la gente había elegido para protegerse.
La reacción se extendió por las comunidades de Bitcoin y de Coldcard en Reddit. Un usuario informó de que había perdido Bitcoin en el exploit, mientras que otro dijo que abandonaba Coldcard.
En otro debate, un propietario de Ledger cuestionó a todas las empresas de carteras de hardware, mientras los comentaristas discutían sobre pasarse a los ETF, Fidelity, Binance o Coinbase.
Estas publicaciones no prueban un cambio más amplio, pero muestran que volver a depender de terceros ya había pasado a formar parte del debate.
Coldcard empujó a algunos titulares de la autocustodia de vuelta a los exchanges
Tras conocerse el fallo, los titulares preocupados por sus claves vulnerables tuvieron que decidir adónde trasladar su Bitcoin. Podían confiar en otra cartera de hardware o dejar que un exchange protegiera las claves por ellos.
Los datos on-chain ofrecen una visión parcial de lo que ocurrió a continuación. El 31 de julio, casi un millón de direcciones de Bitcoin enviaron o recibieron fondos, frente a 645,000 el día anterior, según CryptoQuant. El aumento mostró una carrera por mover Bitcoin, pero no qué causó cada transferencia ni adónde fueron los fondos.
Los depósitos en exchanges aportan una pista más clara. Ese mismo día, la gente depositó en los exchanges más Bitcoin del que retiró. La diferencia fue de 11,163 BTC, según CoinDesk. La mayor parte fue a Binance, River, Kraken y OKX.
No todos los depósitos se pueden vincular a Coldcard. Pero el momento sugiere que algunos titulares eligieron un exchange en lugar de otra cartera de autocustodia.
Sin embargo, los exchanges tienen sus propios riesgos. Muchos titulares de Bitcoin eligen la autocustodia porque los exchanges han sido hackeados o han quebrado en repetidas ocasiones. En 2025, por ejemplo, los atacantes robaron aproximadamente 1.5 mil millones de dólares al exchange Bybit.
Para los titulares que volvieron a los exchanges, el cambio eliminó la incertidumbre inmediata en torno a Coldcard. Pero no eliminó la necesidad de confiar. Simplemente trasladó esa confianza del fabricante de la cartera de vuelta a un exchange responsable de proteger sus claves y de darles acceso a su Bitcoin.
Coldcard no demostró que la autocustodia esté muerta. Mostró que ser dueño de sus claves sigue implicando confiar en las herramientas que las crean.
¿Qué hace que una cartera de hardware sea segura?
Coldcard tenía una sólida reputación. Pero la reputación refleja lo que un producto ha superado antes. No muestra qué partes de su seguridad se han sometido a pruebas independientes.
Términos como código abierto, air-gapped (diseñado para funcionar sin conexión directa a internet) y elemento seguro (un chip diseñado para proteger claves secretas) pueden hacer que una cartera parezca digna de confianza. Son funciones útiles, pero no demuestran que el producto completo sea seguro.
El código público sigue necesitando ser revisado, y un chip certificado no cualifica automáticamente al software encargado de crear y proteger las claves.
Una cualificación formal de seguridad identifica el producto y la versión de software exactos que se probaron, las amenazas incluidas y la organización que realizó la evaluación.
La certificación de la ANSSI del Ledger Nano S Plus, por ejemplo, se aplica solo a la versión y la configuración que se evaluaron. Su objetivo de seguridad incluye amenazas como la generación predecible de números aleatorios y las actualizaciones de firmware maliciosas. Muestra qué se probó, pero no garantiza la seguridad de todas las versiones futuras.
Coldcard muestra por qué esto importa. Su debilidad se introdujo a través del firmware y afectó a la forma en que se creaban las frases de recuperación. Una revisión solo del hardware la habría pasado por alto, mientras que una revisión completada antes de publicarse el firmware vulnerable ya no habría bastado.
Por tanto, una cualificación significativa debe abarcar el hardware, el firmware, la generación de claves y el proceso de actualización. También debe repetirse cuando una actualización cambie la forma en que se crean o se protegen las claves.
La autocustodia elimina la necesidad de confiar en un exchange. No debería sustituir esa confianza por afirmaciones que los usuarios no pueden verificar. La seguridad de las carteras de hardware necesita evidencias claras, y esas evidencias deben renovarse cuando el producto cambia.
🎣 ¿Es phishing?
¿Haría clic para renovar su acceso SSO de GitHub?
🔬 Investigación técnica
La cartera siguió fuera de línea. El atacante encontró la clave de todos modos.
Los robos de COLDCARD notificados en julio de 2026 expusieron el modo de fallo del otro lado del almacenamiento en frío. Los atacantes no necesitaron comprometer el dispositivo, interceptar una transacción, engañar a los usuarios para que aprobaran un pago ni robar frases de recuperación de una copia de seguridad. Los informes públicos vinculan el incidente con una generación débil de semillas en el firmware afectado: las carteras estaban fuera de línea, pero el espacio de semillas posibles era lo bastante pequeño como para recorrerlo.
El primer barrido ampliamente documentado movió aproximadamente 1,082.65 BTC de 1,196 carteras Coldcard en 41 minutos el 30 de julio, por un valor de unos 70 millones de USD en ese momento. Análisis posteriores elevaron el total notificado a cerca de 1,755 BTC en unas 5,000 carteras, con una pérdida próxima a los 116 millones de USD, aunque la estimación siguió cambiando a medida que los investigadores agrupaban transacciones adicionales.
El dispositivo no filtró la clave después de generarla.
La clave parece haber sido adivinable desde el principio.
Los atacantes no tuvieron que entrar en la cartera. Recorrieron en otro lugar el espacio de semillas reducido, encontraron direcciones que contenían bitcoin y recrearon las claves en sus propias máquinas.
Donde la aleatoriedad se convirtió en el límite de seguridad
Una cartera de Bitcoin no almacena un montón de claves privadas independientes. Parte de la entropía: una entrada aleatoria codificada como frase de recuperación. Dadas la misma frase de recuperación y la misma frase de contraseña opcional, BIP-39 siempre produce la misma semilla, de la que la cartera deriva su clave maestra, sus claves privadas, sus claves públicas y sus direcciones.
Esta reproducibilidad es intencionada. Por eso las mismas palabras de recuperación pueden reconstruir la misma cartera años después en otro dispositivo compatible.
También crea una regla estricta: quien reconstruya la misma semilla reconstruye la misma cartera.
Normalmente, esto es computacionalmente irreal. Una frase BIP-39 de 12 palabras generada correctamente representa 128 bits de entropía, mientras que una de 24 palabras representa 256 bits. Los espacios de búsqueda son tan grandes que probar todas las posibilidades no es un ataque práctico.
Pero las palabras no crean la aleatoriedad. Solo la codifican.
Si el generador de números aleatorios solo puede producir un subconjunto limitado o predecible de valores posibles, una frase de recuperación puede seguir pareciendo normal mientras representa mucha menos incertidumbre de la que sugiere su longitud. Veinticuatro palabras bien escritas no equivalen automáticamente a 256 bits de seguridad. Solo son tan fuertes como el proceso que las seleccionó.
Ese es el límite que parece haber roto el incidente de COLDCARD.
El mecanismo de reserva que nunca debió ser posible
COLDCARD publica su repositorio de firmware y admite compilaciones reproducibles, lo que permite inspeccionar directamente esta ruta de código.
En el firmware 4.0.0, COLDCARD cambió la generación de nuevas carteras de su propia ruta de aleatoriedad por hardware ckcc.rng_bytes a random.bytes(32), un envoltorio de la nueva biblioteca libNgU. La implementación prevista de libNgU debía usar el generador de números aleatorios por hardware del STM32.
Un error de configuración de la compilación frustró esa intención. LibNgU comprobaba solo si existía el ajuste del RNG por hardware, mientras que MicroPython comprobaba si estaba habilitado. El ajuste existía, pero valía 0, de modo que la comprobación de libNgU se superaba mientras MicroPython compilaba rng_get() como su alternativa por software.
Esa alternativa se inicializaba con valores específicos del dispositivo y de temporización, no con suficiente entropía secreta nueva. Como resultado, las semillas que parecían normales podían proceder de un conjunto de posibilidades mucho menor y enumerable. El impacto exacto variaba según la generación del dispositivo; el aviso actual de Coinkite es la fuente de referencia para los modelos y rangos de firmware afectados.
La cadena de llamadas resultante era esta:
make_new_wallet()
↓
random.bytes(32)
↓
ngu.random.bytes()
↓
my_random_bytes()
↓
CHIP_TRNG_32()
↓
rng_get() Ese último nombre de función es donde la implementación y la suposición se separaron.
La configuración de la placa COLDCARD definía MICROPY_HW_ENABLE_RNG como 0 porque el proyecto incluía su propia implementación de RNG por hardware. LibNgU intentaba asegurarse de que hubiera un RNG por hardware de STM32 disponible, pero su protección en tiempo de compilación comprobaba solo si MICROPY_HW_ENABLE_RNG estaba definido. No comprobaba si su valor lo habilitaba.
Como la macro existía, libNgU aceptó la compilación y asignó CHIP_TRNG_32() a rng_get() de MicroPython. Como el valor de la macro era cero, MicroPython compiló la otra implementación de rng_get(): un PRNG por software Yasmarang pensado para destinos STM32 sin RNG por hardware habilitado.
El ajuste existía con un valor de 0. Eso bastó para superar la comprobación de existencia de libNgU, pero la comprobación de valor de MicroPython compiló la alternativa por software en lugar de la implementación del RNG por hardware.
La alternativa inicializaba su estado interno a partir de los primeros 32 bits del identificador único del chip combinados mediante XOR con el contador SysTick actual, más dos registros del reloj de tiempo real. Esas entradas pueden variar, pero no equivalen a 256 bits de entropía secreta nueva. LibNgU combinaba mediante XOR esa salida con un segundo flujo de Yasmarang cuyo estado partía de constantes fijas. Mezclar otro flujo determinista cambia la salida; no añade entropía desconocida.
Esa distinción es crítica.
Un TRNG por hardware mide un proceso físico destinado a proporcionar entropía nueva e impredecible. Un PRNG por software expande un estado interno en valores que parecen aleatorios. Un PRNG criptográficamente seguro puede ser seguro cuando parte de suficiente entropía secreta y se resiembra correctamente. Una pequeña alternativa determinista inicializada con valores como identificadores del dispositivo y el estado de un temporizador no es un sustituto aceptable para generar el secreto maestro de una cartera.
Lo peligroso no era simplemente que existiera un generador por software. Era que la ruta de producción podía usarlo en silencio para una operación crítica para la seguridad.
Dos comprobaciones locales hacían que la salida pareciera más segura sin reparar la pérdida de entropía. La creación de la semilla verificaba que los 32 bytes generados contuvieran más de cuatro valores distintos, lo que puede detectar un generador bloqueado pero no distingue una salida predecible de una salida criptográficamente aleatoria. Después calculaba el hash de los 32 bytes con SHA-256 para mitigar el sesgo. El hash puede repartir de manera uniforme una entrada sesgada en la salida, pero no puede crear posibilidades que no existían en el generador original. Si un atacante puede enumerar las entradas, también puede calcular el hash de cada candidato.
La cartera seguía mostrando una frase de recuperación válida. La suma de verificación seguía funcionando. Las direcciones se derivaban con normalidad. Las transacciones se firmaban con normalidad. Nada en la experiencia del usuario anunciaba que la semilla procedía de un espacio de búsqueda mucho menor.
El fallo fue silencioso, persistente e irreversible para cada cartera creada a partir de la aleatoriedad afectada.
Cómo un ataque de fuerza bruta sin conexión se convierte en un robo
Una vez comprendido el comportamiento del RNG, ya no hace falta la cartera física.
Un atacante puede reproducir el generador débil, enumerar sus estados internos plausibles y convertir cada salida en frases de recuperación candidatas. De cada candidata derivan las claves y direcciones de Bitcoin correspondientes.
La blockchain proporciona la capa de verificación.
Las direcciones de Bitcoin y sus saldos son públicos. El atacante no necesita consultar a la víctima, iniciar sesión en un servicio ni activar una alerta en la cartera de hardware. Compara las direcciones derivadas con el historial de la blockchain y se queda con las candidatas que coinciden.
Cuando una semilla candidata deriva una dirección que contiene bitcoin, la búsqueda ha terminado. El atacante posee ahora la misma autoridad de firma que el propietario original de la cartera. Puede recrear la cartera en su propio sistema y producir una transacción que la red de Bitcoin considera completamente válida.
No hay ninguna firma falsificada que la red pueda rechazar. Ningún fallo de contraseña. Ningún flujo de autenticación anómalo.
El atacante tiene la clave.
Por qué 41 minutos no describen todo el ataque
La cifra más dramática de los informes es la ventana de 41 minutos en la que se movieron más de mil bitcoins.
Probablemente fue la fase de ejecución, no el comienzo del trabajo.
Enumerar semillas candidatas, derivar sus direcciones, comprobar sus historiales y priorizar los objetivos con fondos pudo hacerse antes de que apareciera la primera transacción de robo. El barrido rápido sugiere que el atacante pudo haber preparado ya una lista de carteras vulnerables y de claves privadas, y luego recorrió los objetivos de mayor valor en una ráfaga coordinada.
Las transacciones posteriores complican la atribución. Las estimaciones públicas crecieron de 594 BTC iniciales a más de 1,000 BTC, y luego a aproximadamente 1,755 BTC, a medida que se asociaban más oleadas y direcciones con la debilidad. Una temporización o unos flujos de fondos similares pueden respaldar la agrupación, pero no prueban automáticamente que todos los robos procedan de un solo operador.
Por esa razón, la descripción más segura es una estimación on-chain en evolución, y no un recuento final de víctimas ni un total confirmado atribuible a un único atacante.
Por qué actualizar el dispositivo no basta
Una actualización de firmware puede corregir la aleatoriedad usada para crear futuras carteras.
No puede añadir entropía a una semilla que ya existe.
Cada clave privada y dirección derivada de una frase de recuperación afectada sigue vinculada a esa semilla original. Borrar el dispositivo y restaurar las mismas palabras no cambia nada. Importar esas palabras en una cartera de hardware distinta no cambia nada. El nuevo dispositivo simplemente recrea las mismas claves que el atacante quizá ya pueda calcular.
La corrección que de verdad sirve es la migración:
Instale firmware verificado procedente de la fuente oficial del fabricante.
Genere una semilla completamente nueva con un proceso de confianza y no afectado.
Verifique sin conexión el procedimiento de recuperación y la dirección de recepción.
Mueva todos los fondos de las direcciones derivadas de la semilla antigua a la nueva cartera.
Trate como potencialmente expuesta toda cartera hija derivada de la raíz antigua, incluidas las hijas BIP-85.
No introduzca nunca la frase de recuperación en un sitio web, un formulario de soporte, un «verificador» ni una herramienta de recuperación no solicitada.
Los usuarios deben seguir el aviso actual de Coinkite para conocer el alcance definitivo de dispositivos y firmware afectados. Los informes públicos no siempre han usado «cartera», «dirección», «dispositivo» y «usuario» de forma coherente, y esos términos no son intercambiables.
Lo que deberían aprender los equipos de carteras de hardware
Esto no fue un fallo del algoritmo de firma de Bitcoin, de la lista de palabras de BIP-39 ni del consenso de la blockchain. Fue un fallo de implementación en el momento en que se creó un secreto de larga duración.
Eso hace que las lecciones de ingeniería sean inusualmente directas:
Un RNG criptográfico debe fallar de forma cerrada. Si la fuente de entropía prevista no está disponible, la creación de la semilla debería detenerse con un error visible.
El código de producción no debería contener una alternativa silenciosa no criptográfica para la generación de claves.
Las pruebas deben ejercitar la imagen de firmware firmada exacta y la ruta de hardware que se entregan a los usuarios, y no solo el comportamiento a nivel de código fuente o de simulador.
La configuración en tiempo de compilación debería comprobar que la implementación de RNG requerida está activa.
Se pueden combinar fuentes de entropía independientes para que el fallo de un componente no determine por completo la semilla.
La generación de semillas necesita pruebas de respuesta conocida, de inyección de fallos y de rutas negativas, además de pruebas estadísticas de aleatoriedad.
Las compilaciones reproducibles mejoran la transparencia, pero la reproducibilidad solo demuestra que el binario coincide con el código fuente. No demuestra que el código fuente sea seguro.
La custodia multifirma es más sólida cuando las claves se generan de forma independiente, idealmente con implementaciones y proveedores distintos. Repetir el mismo generador débil en todos los firmantes conserva el mismo dominio de fallo.
La lección más amplia resulta incómoda porque la cartera de hardware parece hacer todo bien después de la configuración. Mantiene la semilla fuera de línea. Protege el PIN. Verifica el firmware. Muestra las direcciones en una pantalla de confianza. Firma dentro de hardware dedicado.
Todos esos controles están aguas abajo de la generación de la semilla.
Si el primer secreto es predecible, el resto de la arquitectura puede estar protegiendo una clave que el atacante es capaz de recrear por su cuenta.
El air-gapping protege un secreto para que no salga del dispositivo.
No puede proteger un secreto que nunca fue lo bastante secreto.
Nota de versión y alcance: esta sección refleja la información pública disponible el 10 de agosto de 2026. Los totales de pérdidas, los grupos de transacciones y el alcance preciso de los dispositivos afectados seguían evolucionando. La cifra de 116 millones de USD es una estimación, no un total de pérdidas auditado y definitivo.
Fuentes: TRM Labs, CoinDesk, aviso de seguridad de Coinkite, repositorio de firmware de COLDCARD, código de generación de semillas del firmware 4.0.0, configuración del RNG de la placa COLDCARD, implementación del RNG de libNgU fijada a un commit, implementación del RNG de STM32 de MicroPython fijada a un commit, historial de firmware de COLDCARD, especificación BIP-39
🛠️ Herramienta de la semana
LLVM
La mayoría de la gente piensa que un compilador tiene una sola función: convertir el código fuente en una aplicación que funcione.
LLVM muestra cómo la compilación también puede formar parte de las pruebas de seguridad. La infraestructura de código abierto que hay detrás de Clang puede insertar comprobaciones mientras se compila el software, ayudando a los equipos de seguridad a descubrir errores de memoria y a guiar a los fuzzers hacia código que las pruebas ordinarias quizá nunca alcancen.
Cómo apoya LLVM las pruebas de seguridad
Clang traduce el código fuente C y C++ a un formato interno que LLVM puede analizar y modificar antes de producir la aplicación final.
Durante este proceso, herramientas como AddressSanitizer pueden añadir comprobaciones que detectan problemas de memoria, como los intentos de acceder a datos fuera de un área permitida o de reutilizar memoria después de liberarla.
LLVM también incluye libFuzzer. Este envía repetidamente entradas modificadas a un programa y registra qué partes del código alcanzan. Las entradas que descubren un comportamiento nuevo se conservan y se vuelven a modificar, lo que permite al fuzzer explorar cada vez más a fondo la aplicación.
Un ejemplo sencillo
Imagine que una empresa mantiene una biblioteca de C++ que procesa archivos de imagen.
Un ingeniero de seguridad compila la biblioteca con Clang y habilita AddressSanitizer. A continuación conecta libFuzzer a la función encargada de abrir imágenes y proporciona varios archivos válidos como entradas iniciales.
LibFuzzer modifica continuamente esos archivos mientras supervisa qué partes del analizador se alcanzan. Finalmente, una imagen malformada activa una ruta de código poco utilizada y provoca un error de memoria.
AddressSanitizer informa de dónde se produjo el error, lo que da al equipo una entrada reproducible y un punto de partida claro para investigar.
Lo que no sustituye
LLVM es un proyecto de infraestructura, no un escáner de seguridad que se pueda simplemente apuntar a una aplicación.
Utilizar sus capacidades de seguridad normalmente requiere acceso al código fuente y al proceso de compilación, además de un objetivo de fuzzing adecuado. No identificará automáticamente fallos de autorización, lógica de negocio insegura ni vulnerabilidades que sus pruebas nunca alcancen.
Estas comprobaciones adicionales también pueden hacer que una aplicación se ejecute más despacio, por lo que las compilaciones instrumentadas suelen usarse para pruebas y no se entregan a los usuarios.
👏 Persona de la semana
Andrea Fioraldi
Esta semana destacamos a Andrea Fioraldi , investigador de seguridad centrado en el fuzzing y el descubrimiento automatizado de vulnerabilidades.
Andrea es uno de los mantenedores de AFL++, un fuzzer de código abierto impulsado por la comunidad que reúne en una herramienta práctica las técnicas desarrolladas a lo largo de años de investigación en seguridad.
Su trabajo incluye también LibAFL, un framework para construir fuzzers personalizados, y QASan, que ayuda a detectar errores de memoria en software compilado cuando no se dispone de su código fuente. Su tesis doctoral sobre técnicas modernas de fuzzing recibió el Premio de Tesis 2024 del GDR Sécurité Informatique.
Por ayudar a convertir la investigación sobre fuzzing en herramientas prácticas de código abierto para descubrir vulnerabilidades de software, Andrea Fioraldi es nuestra Persona de la semana.
📅 Evento de la semana
Ekoparty Security Conference 2026
Se esperan miles de investigadores de seguridad, profesionales y aficionados en Buenos Aires para la 22.ª edición de Ekoparty , la mayor conferencia de hackers de América Latina.
A lo largo de tres días, el evento combina charlas técnicas y talleres con CTF, villages comunitarios, actividades de hacking en vivo y desafíos prácticos.
Su programa abarca hacking móvil, ingeniería inversa, fuzzing, explotación, firmware, seguridad en la nube y hacking de hardware.
Para los equipos de AppSec y de seguridad ofensiva, Ekoparty reúne en un solo evento nuevas investigaciones de seguridad, demostraciones prácticas y actividades de aprendizaje con práctica directa.
📍 Centro de Convenciones de Buenos Aires, Argentina
📅 7–9 de octubre de 2026
📚 Libro de la semana
Black Hat GraphQL
De Nick Aleks y Dolev Farhi
¿Cómo se prueba una API que permite a los clientes decidir exactamente qué datos quieren?
Black Hat GraphQL explica cómo funcionan las API de GraphQL y cómo pueden los profesionales de la seguridad examinar su superficie de ataque. Abarca el reconocimiento, la divulgación de información, las omisiones de autenticación y autorización, la inyección, los ataques de denegación de servicio y la falsificación de solicitudes.
Mediante laboratorios prácticos y una aplicación GraphQL deliberadamente vulnerable, los lectores aprenden a identificar debilidades, validar controles de seguridad e incorporar pruebas automatizadas al pipeline de desarrollo.
Es una lectura útil para pentesters, ingenieros de AppSec, analistas de seguridad y desarrolladores que desean una comprensión práctica de cómo se ataca y se protege una API de GraphQL.
😅 El meme
Si tanto las carteras de hardware como los exchanges requieren confianza, ¿qué evidencia deberían exigir los titulares de Bitcoin antes de decidir dónde guardar su Bitcoin?
The Breach Brief, Equipo de Ostorlab