Hacks cripto del tercer trimestre de 2026: 1.180 millones de dólares perdidos, y el 77 % pasó fuera de las revisiones de seguridad

Entre el 1 de julio y el 28 de septiembre de 2026 se robaron 1.180,8 millones de dólares en 107 incidentes, un 55 % más que en el segundo trimestre. Lo afirma Hacken, una empresa de seguridad blockchain, en su informe trimestral. Lo que merece una lectura atenta no es el total: según Hacken, el 77 % de las pérdidas, 906,8 millones, pasó por un proveedor comprometido, una corrección ya pública pero aún no desplegada o un componente fuera de la última revisión de seguridad. Este artículo repasa los casos uno por uno, con fuentes primarias donde existen, y separa lo documentado de lo que sigue siendo una estimación.

El trimestre en las cifras de Hacken

El informe cubre del 1 de julio al 28 de septiembre de 2026. Las cifras principales, todas del documento de Hacken:

• 1.180,8 millones de dólares robados en 107 incidentes, un 55 % más en valor que en el segundo trimestre.
• Los contratos inteligentes de aplicación sumaron 71 de los 107 incidentes pero solo 228,2 millones, el 19 % de las pérdidas. La mayor parte del valor salió por código a nivel de cadena, proveedores, custodia y wallets.
• Por tipo de ataque, Hacken atribuye el 48 % de las pérdidas a exploits de contratos inteligentes y el 40,4 % (477,6 millones) a control de accesos y fallos operativos.
• Las multas impuestas en todo el mundo a proveedores de servicios cripto fueron de solo 450.000 dólares.

Una comparación prudente: otras firmas de seguimiento cuentan cifras distintas para el mismo periodo, porque cambian las fechas de referencia, los umbrales de inclusión y los criterios de valoración. Informes secundarios sitúan, por ejemplo, a CertiK en torno a 1.260 millones. No hemos leído ese informe directamente, así que lo citamos solo como orden de magnitud. Lo importante es que las estimaciones convergen en un trimestre cercano a los 1.200 millones.

El 77 %: tres vías, once incidentes

La tabla de Hacken es el núcleo del documento. Dice que tres rutas de ataque concentraron la mayor parte de las pérdidas en solo 11 incidentes:

Dos observaciones para leerla bien. Primera: el 77 % no significa «77 % de culpa de los proveedores». Los proveedores comprometidos son la primera vía, con el 35 %. Las otras dos se refieren a correcciones ya públicas pero no aplicadas y a componentes que ninguna revisión reciente había cubierto. Quien cite «el 77 % de los hacks viene de los proveedores» está leyendo mal la tabla. Segunda: solo dos incidentes de proveedores, 411,5 millones, superan a los otros 96 incidentes juntos (274,0 millones). Esa desproporción, más que el total, explica por qué el tema importa.

Una precisión útil para quien siga los casos: la tabla de las tres vías no incluye Coldcard. Hacken lo trata aparte, en la sección sobre incidentes en los que revisiones anteriores no vieron las condiciones del problema. Lo contamos más abajo.

Bitget: 387,5 millones por un producto de seguridad de terceros

Lo documentado. El 24 de septiembre de 2026 a las 18:31 UTC un atacante inició las primeras transferencias no autorizadas desde ciertas hot y warm wallets de Bitget; a las 19:05 el sistema de conciliación detectó la anomalía y el control de riesgos bloqueó automáticamente los retiros. Así lo afirma la página oficial de Bitget sobre el incidente. Hacken sitúa el robo en 387,5 millones de dólares en 11 blockchains, entre ellas Ethereum, XRP Ledger, TRON, Arbitrum, Base y BNB Chain, con XRP como mayor activo individual, unos 158 millones. Bitget da una cifra «final verificada» de unos 388 millones en 12 direcciones.

Cómo, según Bitget. La empresa dice que el atacante explotó una vulnerabilidad zero-day en un producto de seguridad de terceros, obtuvo credenciales internas de alto privilegio y escribió en el sistema de wallets órdenes de retiro falsificadas, que el sistema trató como retiros normales, eludiendo los controles de riesgo. Tras las transferencias, añade Bitget, los responsables borraron rastros. Las claves privadas y las cold wallets, dice el exchange, no se vieron afectadas. El 30 de septiembre Bitget publicó dos informes independientes, de Mandiant (Google Cloud) y SlowMist, que según su versión confirman la ruta del ataque. Hacken añade que los informes, difundidos por Bitget, sitúan la entrada en el producto de terceros y fechan la primera actividad maliciosa en los registros disponibles el 31 de agosto, casi cuatro semanas antes del robo.

Lo no documentado. En las fuentes que pudimos leer no se nombra al proveedor del producto. Por tanto no podemos atribuir responsabilidad a ninguna empresa concreta, y no lo hacemos. Hacken informa además de que Bitget considera «muy probable» una implicación norcoreana, citando el comportamiento de las direcciones IP. Es una valoración de parte, no una atribución confirmada por una autoridad, y la recogemos como tal. Los informes de Mandiant y SlowMist los hemos leído solo a través de la página de Bitget y del informe de Hacken.

Los usuarios. Bitget afirma que los saldos de los usuarios no se vieron afectados y que el impacto se cubre con su propio fondo de protección. Hacken registra que los operadores cubrieron unos 410 millones de dólares a los usuarios con fondos propios, de los cuales 387,5 millones fueron el fondo de protección de usuarios de Bitget. Los retiros se restablecieron por fases: BTC el 28 de septiembre, ETH el 29, USDT el 30 y el resto el 2 de octubre. Una nota de lectura: la página de Bitget da cifras distintas del fondo de protección en lugares distintos (en la cabecera 3.705 BTC y más de 314 millones de dólares, en las preguntas frecuentes 5.500 BTC y más de 464 millones). Pueden referirse a fechas diferentes, pero quien quiera verificar el dato debería mirar las direcciones on-chain que declara el exchange, no el resumen.

La recuperación. Según Hacken, Circle y Tether congelaron del robo de Bitget solo unos 0,34 millones de dólares. El rastreo de los fondos, dice Bitget, continúa, y la empresa ofrece una recompensa del 5 % sobre los importes congelados o recuperados gracias a pistas comunicadas.

Liquid Network: 36 minutos y una corrección a medias

Liquid es el caso que mejor ilustra la segunda vía de Hacken, «corrección pública explotada antes del despliegue». La secuencia, a partir del informe y del repositorio del software Elements, sobre el que se construye Liquid:

• 1 de septiembre: una corrección parcial, que añade el contexto de la transacción a la clave de la caché, es pública en el repositorio de Elements. Deja ambigua la codificación.
• 6 de septiembre: un atacante explota la ambigüedad en la caché de verificación de range proofs, las comprobaciones que demuestran que un importe es válido sin revelarlo. Una prueba validada para un activo y un contexto se reutiliza en otro. Resultado: se acuñan 3.998,5 L-BTC sin los BTC correspondientes. Un peg-out de unos 4.000 BTC se confirma después en Bitcoin.
• 7 de septiembre: el atacante, que se define como white hat, devuelve unos 3.400 BTC (272 millones de dólares) con la condición de que se corrija el fallo, y se queda con 598,5 BTC, unos 47 millones, como recompensa autoasignada.
• 8 de septiembre: se integra la corrección completa (pull request n.º 1600 del repositorio de Elements, comprobada por nosotros). 9 de septiembre: sale Elements 23.3.4.

Dos cautelas. La devolución del 85 % es un hecho documentado por Hacken, pero «white hat» es la etiqueta del propio atacante, no un juicio de terceros: en las fuentes que leímos no consta ninguna autorización previa para quedarse esos 47 millones, y llamarlos recompensa es una definición del propio atacante. Segunda, la lección de Hacken se refiere a la gestión del ciclo de correcciones: entre el parche público parcial y el lanzamiento de la corrección definitiva pasaron ocho días. Los registros públicos muestran la cronología; no establecen cómo encontró el atacante el fallo, y no afirmamos saberlo.

Tectonic y Cronos: un precio correcto que no se podía usar

El 30 de agosto, según el post-mortem publicado por Cronos y recogido por crypto.news, un atacante manipuló el precio de TONIC, el token de gobernanza, poco negociado, del protocolo de préstamos Tectonic, y lo usó como garantía para pedir prestados 120,4 millones de dólares en nueve mercados. Hacken añade que el precio se empujó al alza contra una liquidez escasa en unos 11 minutos y que Tectonic aceptó el precio inflado como valor de la garantía.

El punto, que Hacken extrae de los parámetros publicados del protocolo, es que ninguno de los tres controles que podrían haberlo detenido estaba en vigor: un límite de profundidad de liquidez, un límite de velocidad sobre lo rápido que la capacidad de préstamo podía seguir al precio spot, y un tope de préstamos que funcionara. Los parámetros de Tectonic indican un tope de préstamos de 0 en cada mercado, y en su código derivado de Compound un cero significa «sin tope». El cofundador de RedStone, Marcin Kazmierczak, dijo a crypto.news que no fue un fallo del oráculo: el oráculo informó correctamente del precio del mercado que vigilaba, y el protocolo lo aceptó sin considerar si había liquidez suficiente para vender la garantía a ese valor. El código de Tectonic había pasado cuatro auditorías, una de ellas sobre la lógica central de préstamos. Hacken traza una distinción importante: comprobar que un contrato calcula bien la garantía no establece que los parámetros de un activo de garantía concreto sean seguros en su mercado real. Eso es lo que la tabla llama «componente fuera de la última revisión».

La respuesta fue inusual. Los validadores de Cronos detuvieron la cadena en el bloque 90.907.150 y la restauraron al bloque 90.896.188, el último antes del ataque, descartando 10.961 bloques, es decir, 1 hora y 54 minutos de historia. Se revirtieron unos 111,2 millones de los 120,4 implicados. Quedan fuera de alcance 9,19 millones (7,6 %) que ya habían salido de la cadena. El post-mortem de Cronos reconoce que fue una «decisión difícil» y que el rollback borró también las transacciones de usuarios normales en la misma ventana. El precio de la recuperación fue renunciar, en ese caso, a la irreversibilidad de la historia ya registrada, un principio que muchos consideran central en las blockchains públicas. Hacken lo señala como una laguna regulatoria: ninguno de los marcos que revisó exige a las empresas declarar si la liquidación en una cadena puede revertirse.

Coldcard: un error de compilación que sobrevivió cinco años

Aquí Hacken no describe un proveedor comprometido. Coldcard trata de la entropía, es decir, la aleatoriedad con la que se generan las semillas. Por eso lo tratamos aparte de la tabla del 77 % y lo mantenemos distinto del caso Ledger, que es un ataque a la distribución y no un defecto de diseño.

Lo que dice el fabricante. Coinkite, que fabrica Coldcard, publicó un análisis técnico. Según la empresa, un cambio de 2021 al pasar a una biblioteca de operaciones de curva elíptica hizo que la generación de semillas recurriera al generador pseudoaleatorio de software de MicroPython en lugar del generador de hardware. Coinkite describe un error de integración en la compilación y el enlazado, no una decisión de diseño: en sus palabras, «no hubo ningún fallback intencionado» hacia un generador débil. La condición del código comprobaba si un ajuste estaba definido en vez de si estaba activado, así que la compilación no se detuvo. Las versiones afectadas son el firmware 4.0.1 a 4.1.9 para Mk2 y Mk3, y las versiones equivalentes de los modelos posteriores. Coinkite estima, con carácter preliminar, un espacio de búsqueda efectivo de unos 40 bits en Mk2 y Mk3 y de unos 72 bits en Mk4, Mk5 y Q, frente a los 128 bits previstos para una semilla de 12 palabras. La empresa afirma también que los dispositivos no fueron hackeados ni controlados a distancia: los atacantes regeneraron offline las claves correspondientes.

Lo que dicen los datos del robo. Los primeros vaciados comenzaron el 30 de julio. TRM Labs, en un análisis del 5 de agosto, ya contaba unos 1.816 BTC (alrededor de 116 millones de dólares) de más de 5.200 direcciones en cuatro oleadas, citando el recuento de Galaxy Research, y subrayaba que los datos eran preliminares y que los patrones de transacción sugerían más de un atacante: TRM no atribuyó el robo a un actor concreto. En su informe posterior, Hacken da 1.789,28 BTC en 8.865 direcciones atribuidas por Galaxy Research al incidente, unos 114,7 millones de dólares en el momento del robo, y estima las pérdidas en unos 115 millones. Las cifras difieren porque tienen fechas y métodos distintos. A principios de agosto circulaba entre investigadores externos una estimación de unos 130 millones; Coinkite dijo que no especularía sobre la magnitud de las pérdidas y que publicaría un análisis completo cuando fuera seguro hacerlo.

El punto que importa para esta investigación. Hacken escribe que una revisión de pago de marzo de 2022 cubrió el endurecimiento de la entropía pero no identificó la condición de compilación. Coinkite lo confirma en lo esencial: la revisión existente «confirmó que la implementación TRNG prevista estaba presente en el binario del firmware, pero no verificó qué implementación alcanzaba realmente la ruta de generación de semillas». Ese es el tema del informe: una comprobación que mira el componente correcto puede pasar por alto la conexión equivocada. El defecto, dice Hacken, pasó más de cinco años sin detectarse. Coinkite añade que pocas semanas antes del incidente usó uno de los mejores modelos de inteligencia artificial disponibles para revisar su código, y no encontró el problema. Es una afirmación de la empresa; no la hemos verificado.

Qué significa para quien la tiene. Actualizar el firmware no repara las semillas ya generadas. Según Coinkite, las semillas creadas en firmware afectado sin al menos 50 tiradas de dados independientes y privadas, y sin una passphrase BIP-39 fuerte y única, deben considerarse en riesgo y sustituirse generando una semilla nueva en firmware corregido y moviendo los fondos. La empresa no considera en riesgo, solo por este fallo, las semillas creadas con al menos 50 tiradas de dados. Las instrucciones completas están en su aviso oficial: síguelas desde allí, no desde un resumen.

Fuera de los datos del trimestre: el caso Ledger

El periodo de Hacken termina el 28 de septiembre. El incidente Ledger/CryptoBilis es de octubre: los primeros vaciados se comunicaron el 9 de octubre, y sobre las pérdidas solo existen estimaciones de terceros, entre 86 y 103 millones de dólares. No está por tanto en las cifras de este artículo, y Ledger no ha publicado un total. Pero es el mismo patrón en otra forma: una parte de la cadena, aquí la distribución, queda fuera de lo que inspeccionan las revisiones de seguridad. Reconstruimos el caso, con lo confirmado y lo no confirmado, en nuestro artículo Implante LTE en Ledger: qué está confirmado y qué no.

Hay un pasaje del informe de Hacken que conecta los dos mundos. Su análisis de las normas europeas observa que ninguno de los marcos examinados cubre los dispositivos que los clientes compran para la autocustodia, y que DORA solo alcanza a un proveedor de hardware cuando presta servicios a una empresa regulada. El defecto de Coldcard, señala Hacken, pasó más de cinco años sin detectarse. Quien compra hoy una hardware wallet queda, en la práctica, fuera de casi todas las protecciones regulatorias sobre la seguridad de los componentes.

La recuperación: un tercio, por mecanismos muy distintos

Hacken calcula que unos 387 millones de dólares, el 33 % de las pérdidas brutas, se devolvieron o revirtieron. El informe distingue tres mecanismos que funcionan de forma distinta y no son equivalentes:

• Devolución por el atacante: 272 millones (Liquid Network, el 85 % de los 319 millones sustraídos). Depende por completo de la voluntad de quien tomó los fondos.
• Intervención en el estado de la cadena: unos 116 millones, entre ellos el rollback de Cronos (111,2 millones de los 120,4 implicados), una restauración desde snapshot en BounceBit y una incautación de 2,1 millones en ATOM en Cosmos Hub. Depende de los validadores y cuesta finalidad.
• Congelación por parte de los emisores: unos 0,34 millones (Circle y Tether, del robo de Bitget). Depende del emisor y de la rapidez.

Además, los operadores cubrieron unos 410 millones de dólares a los usuarios con fondos propios; esos usuarios fueron compensados mientras los activos robados siguieron en manos de los atacantes. El cuadro es claro: la recuperación real desde el mercado fue pequeña, y la red de seguridad fue sobre todo la solidez patrimonial de quienes gestionaban los fondos.

Qué hacen los reguladores, según Hacken

La parte regulatoria del informe es más breve pero contiene dos señales. Primera, los reguladores empiezan a comprobar si los controles aguantan en el funcionamiento continuo y no solo en un único momento de revisión. Segunda, Hacken observa que los reguladores atribuyen cada vez más responsabilidad personal a fundadores y directivos por exploits e incidentes. Las multas en todo el mundo a proveedores de servicios cripto, 450.000 dólares, son minúsculas frente a 1.180 millones robados. Señalamos la comparación sin sacar una conclusión sobre el sistema sancionador: son datos sobre cosas distintas (sanciones impuestas y pérdidas sufridas) y abarcan jurisdicciones distintas.

Qué significa para ti

Esta sección es información general, no asesoramiento financiero.

Si tienes fondos en un exchange

El caso Bitget muestra que una prueba de reservas mide una cosa y un ataque golpea otra. Una proof of reserves dice si el exchange declara activos suficientes para cubrir los saldos; no dice nada sobre lo protegidos que estén los accesos internos y los sistemas de retiro. Sigue siendo una herramienta útil, pero no responde a cómo gestiona una empresa a sus proveedores. Cómo leerla y verificarla lo explicamos en nuestra guía de proof of reserves. En este trimestre, según Hacken, los usuarios de los exchanges afectados fueron compensados por los operadores: no es una garantía para todos los casos futuros, es un hecho observado de este periodo.

Si practicas la autocustodia

• Si tienes una Coldcard, consulta el aviso oficial de Coinkite para tu modelo y la fecha de creación de tu semilla. Actualizar el firmware no basta.
• Si vas a comprar una hardware wallet, cómprala al fabricante y desconfía de los canales no oficiales. El caso Ledger es la demostración.
• No dependas de un solo dispositivo para una suma importante. TRM Labs, al comentar el caso Coldcard, observa que las configuraciones multifirma que combinan dispositivos diseñados de forma independiente y entropía generada de forma independiente ofrecen defensa en profundidad, porque reducen la dependencia de una sola implementación. Es una configuración que exige cuidado: nuestra guía de multisig 2 de 3 explica cómo. Y recuerda que un plan de custodia completo incluye también quién puede acceder a los fondos si tú no puedes: el plan de herencia de Bitcoin.

Si usas finanzas descentralizadas

El caso Tectonic no trata de código equivocado en sentido estricto. Trata de los parámetros de un solo activo en un protocolo de préstamos. Cuando un protocolo acepta como garantía un token poco negociado, el precio «correcto» puede no ser un precio utilizable. Antes de depositar en un protocolo, conviene saber qué activos acepta como garantía y si existen límites de préstamo reales, no fijados en cero.

Lo que todavía no sabemos

• El nombre del proveedor del producto de seguridad usado por Bitget. No aparece en las fuentes consultadas.
• La identidad de los atacantes de Bitget, Liquid, Tectonic y Coldcard. Bitget considera probable una responsabilidad norcoreana, pero es una valoración de parte.
• El balance final de Coldcard: TRM y Hacken llaman preliminares a los datos, y Coinkite aún debe publicar su análisis completo.
• Si los informes de Mandiant y SlowMist sobre Bitget se harán públicos íntegros. Los leímos solo en los resúmenes de Bitget y de Hacken.
• La parte de las pérdidas del trimestre aún no contabilizada. Hacken y TRM advierten de que las víctimas suelen aparecer meses después.
• Hasta qué punto la decisión de Hacken, una firma que vende revisiones de seguridad, de clasificar las pérdidas como «fuera de la última revisión» depende de cómo trazó sus categorías. La clasificación es suya, y otro analista podría trazar los límites de otro modo.

Nuestra valoración

Los hechos documentados dicen algo preciso y menos cómodo que el relato habitual sobre los hacks. En el tercer trimestre de 2026 la mayor parte del dinero no salió por un contrato mal escrito, sino por puntos de la cadena que ninguna revisión estaba mirando: la herramienta de seguridad de un proveedor, un fallo cuya corrección era pública pero incompleta, un parámetro de riesgo, una línea de configuración del compilador. Los contratos inteligentes de aplicación, el objetivo tradicional de las auditorías, produjeron la mayoría de los incidentes pero solo el 19 % de las pérdidas.

Esto no hace inútiles las auditorías, y no autoriza a decir que la culpa sea de los proveedores. Quien gestiona un exchange o un protocolo elige a sus proveedores, y el propio Hacken señala que las revisiones no cubrían componentes que, sin embargo, podían tocar precios, mensajes, gobernanza o préstamos. Para el lector común queda un criterio práctico: la pregunta sobre un servicio no es solo «¿se ha verificado?», sino «¿qué no se ha verificado?». Pocos operadores responden de forma explícita a esa segunda pregunta, y los datos de este trimestre sugieren que es la que más importa.

Actualizaremos este artículo si Coinkite publica su análisis completo, si Bitget hace públicos los informes independientes o nombra al proveedor implicado, o si Hacken revisa sus cifras.

Preguntas frecuentes