Bitget perdió aproximadamente $387.5 millones el 24 de septiembre de 2026, después de que atacantes explotaron un producto de seguridad de terceros, obtuvieron credenciales internas de alto nivel y emitieron comandos de retiro falsificados a través de la infraestructura de billeteras de la bolsa.
El incidente es el mayor robo de criptomonedas de 2026 hasta la fecha y el mayor robo individual atribuido a Corea del Norte en 2026, según evaluaciones analíticas recientes. La primera estimación de Bitget fue de $351.6 millones, pero la cifra aumentó tras rastrear transferencias adicionales de Zcash y TRON. Las primeras estimaciones independientes en la cadena situaron la pérdida entre aproximadamente $174 millones y $183 millones.
Resumen clave: La explotación de Bitget no fue un robo convencional de claves privadas. Los atacantes comprometeron una capa de seguridad confiable, hicieron que las instrucciones de retiro malicioso parecieran legítimas para el proceso de autorización y utilizaron billeteras calientes y tibias para mover aproximadamente $387.5 millones antes de que los controles detuvieran la fuga.
¿Cómo logró el hackeo de Bitget evadir los controles de seguridad de la bolsa?
El hackeo de Bitget evadió los controles de seguridad de la bolsa comprometiendo un sistema crítico de backend conectado a la infraestructura de billeteras, obteniendo credenciales internas, falsificando datos de transacción e inyectando comandos de retiro fraudulentos. Bitget afirmó que los comandos pasaron los controles de riesgo de la bolsa porque el proceso de autorización recibió información de transacción que parecía representar retiros rutinarios y legítimos.
Bitget describió la vulnerabilidad de terceros como un zero-day durante una transmisión en vivo, mientras que su explicación formal usó un lenguaje más cauteloso. La bolsa no ha mencionado al proveedor. Bitget informó que notificó al proveedor, compartió detalles de la vulnerabilidad y desactivó la funcionalidad afectada mientras se implementaba una solución.
La cadena del ataque puede representarse en cinco etapas interconectadas:
- Compromiso de terceros: El atacante explotó una vulnerabilidad en un producto de seguridad utilizado en el entorno de Bitget.
- Acceso a credenciales: El atacante obtuvo credenciales internas de alto nivel.
- Manipulación del backend: El atacante comprometió un sistema crítico del backend dentro de la infraestructura de billeteras.
- Falsificación de transacciones: El atacante alteró o falsificó datos de transacción presentados al proceso de autorización.
- Ejecución del retiro: Los comandos de retiro falsificados bypassaron los controles de riesgo y movieron activos desde billeteras calientes y tibias.
La distinción entre compromiso de claves de firma y compromiso de capa de autorización es importante. Bitget afirmó que las billeteras en cold, las claves privadas, los saldos de las cuentas de usuario y la billetera autoservicio de Bitget no fueron comprometidas. Las operaciones de trading y depósitos continuaron, aunque se bloquearon los retiros a nivel de plataforma después de que el sistema de conciliación detectara una discrepancia.
Por lo tanto, el ataque se dirigió a la capacidad de la bolsa para determinar si una solicitud de retiro era confiable. Un comando de apariencia válida puede ser peligroso incluso cuando la firma criptográfica permanece intacta. Si el sistema que prepara, describe, enruta o aprueba una transacción está comprometido, el proceso de firma puede autorizar fielmente una instrucción que la bolsa nunca tuvo intención de emitir.
“En nuestra experiencia auditando contratos inteligentes e infraestructura de billeteras en Soken, la integridad de la autorización es más amplia que la protección de claves privadas. Un sistema puede mantener sus claves y aun así perder control de los fondos cuando los datos del backend comprometido se tratan como una descripción autorizada de lo que un firmante está aprobando.”
El incidente de Bitget también incluyó evidencia de actividad anti-forense. El atacante eliminó rastros de los comandos inyectados, lo cual Gracy Chen denominó la parte más complicada de la operación. Esa conducta genera un requerimiento específico en la respuesta a incidentes: las bolsas deben mantener registros independientes e a prueba de manipulaciones de la creación, aprobación, firma y difusión de los comandos.
Un diseño seguro no debería depender de un solo sistema interno para construir una solicitud de retiro y describir esa solicitud al aprobador. La reconstrucción independiente de transacciones, verificaciones de políticas fuera de banda, registros inmutables y una separación estricta entre herramientas de seguridad y operaciones de billeteras pueden hacer que las instrucciones falsificadas sean más fáciles de detectar.
¿Qué sucedió durante la línea de tiempo del exploit de Bitget?
El exploit de Bitget avanzó desde pequeñas transferencias de prueba hasta un drenaje multi-cadena antes de que la conciliación automatizada detectara una discrepancia. Las primeras transferencias no autorizadas aparecieron a las 18:31 UTC del 24 de septiembre de 2026. Luego, el drenaje principal ocurrió desde las 18:58 hasta las 20:09 UTC en 17 transacciones a través de 8 cadenas, mientras que la última transferencia del atacante se observó a las 21:23 UTC.
| Fecha u hora | Evento en el incidente de Bitget | Significado de seguridad |
|---|---|---|
| 18:31 UTC, 24 de septiembre | Se detectaron las primeras transferencias no autorizadas desde billeteras calientes y tibias | Dos transferencias de prueba, 0.184 ETH y 193 TRX, quedaron por debajo de los umbrales de riesgo |
| 18:58 a 20:09 UTC, 24 de septiembre | El drenaje principal en 17 transacciones en 8 cadenas | Aproximadamente $361 millones movidos durante la secuencia principal |
| 19:05 UTC, 24 de septiembre | El sistema de conciliación detectó una discrepancia | Se bloquearon los retiros en toda la plataforma |
| 20:40 UTC, 24 de septiembre | Bitget empezó a mover fondos restantes a almacenamiento en cold | La exposición residual en las billeteras se redujo |
| 21:23 UTC, 24 de septiembre | La última transferencia en cadena del atacante | La transferencia final ocurrió 2 horas y 52 minutos después de la primera prueba |
| 21:44 UTC, 24 de septiembre | Se cerraron servicios de billetera y firma | Se detuvieron las operaciones de firma |
| 25 de septiembre, 08:43 UTC | Bitget identificó la causa raíz | La investigación pasó de la contención a la remediación |
| 25 de septiembre, 13:42 UTC | Se notificó a las autoridades | Comenzó la escalada externa del incidente |
| 28 de septiembre, 08:00 UTC | Se reanudaron los retiros en BTC | Inicio de reapertura por fases |
| 29 de septiembre, 08:00 UTC | Se programó reabrir los retiros en ETH | La siguiente fase tras la reapertura de BTC |
| 30 de septiembre, 08:00 UTC | Se programaron los retiros en USDT | La ejecución de fases posteriores no fue confirmada en la información disponible |
| 2 de octubre, 08:00 UTC | Se programaron otros tokens, fiat y P2P | El plan de reapertura cubrió servicios adicionales |
Las dos transferencias iniciales fueron diseñadas para pasar por debajo de los umbrales existentes. Las cantidades de prueba, 0.184 ETH y 193 TRX, no activaron alertas. Esto evidencia por qué la monitorización solo por umbrales es débil contra ataques escalonados. Un actor malicioso puede primero validar que una ruta de autorización funciona y luego aumentar el tamaño de las transacciones una vez que el sistema parece estable.
La línea de tiempo de Bitget y la investigación en cadena difieren ligeramente en los límites precisos del drenaje principal. El CEO de Bitget aseguró que la secuencia central ocurrió de 18:58 a 20:09 UTC, mientras que los datos en cadena mostraron picos alrededor de las 19:01 y 19:16 UTC. Esos detalles no modifican la conclusión fundamental: el atacante tuvo una ruta de retiro funcional por menos de tres horas antes de que se observara la última transferencia.
La primera hora tras la reapertura de los retiros en BTC procesó más de 3,000 BTC, según el CEO de Bitget. Este detalle operativo importa, porque reabrir una bolsa tras un incidente con billeteras crea un segundo problema de control. La plataforma debe restaurar el acceso de clientes sin volver a introducir la ruta de aprobación comprometida o permitir un aumento de retiros legítimos que oculte actividad no autorizada adicional.
Por lo tanto, una reapertura por fases es más que un cronograma de atención al cliente. Es una estrategia de contención que permite monitoreo específico de activos, conciliación de billeteras, rotación de credenciales y validación progresiva de controles de retiro.
¿Qué activos se vieron afectados y cómo se desarrolló la pérdida de $387.5 millones?
La estimación final de pérdida de Bitget fue de aproximadamente $387.5 millones en 13 activos y 11 redes, aunque los rastreadores independientes reportaron entre 7 y 11 redes afectadas. XRP representó la mayor exposición en un solo activo con aproximadamente 102.98 millones de XRP, valorados en unos $157.8 millones, mientras que ETH aportó aproximadamente $126.6 millones en el desglose en cadena.
Las divulgaciones públicas y las investigaciones en cadena reportaron el siguiente desglose aproximado de activos:
| Activo | Cantidad o valor aproximado | Detalle observado |
|---|---|---|
| XRP | 102.98 millones de XRP, aproximadamente $157.8 millones | Mayor exposición en un solo activo |
| ETH | Aproximadamente $126.6 millones | Parte del drenaje multi-cadena |
| USDT en Arbitrum | Aproximadamente $19.7 millones | Exposición en stablecoin en Arbitrum |
| AVAX | Aproximadamente $16.8 millones | Incluido en el desglose de activos rastreados |
| BNB | Aproximadamente $9.9 millones | Incluido en el desglose de activos rastreados |
| TRX | Aproximadamente $7.0 millones | Cantidad confirmada por múltiples rastreadores |
| Pérdida total de Bitget | Aproximadamente $387.5 millones | Actualizada tras rastrear transferencias de Zcash y TRON |
El conjunto de activos robados incluyó XRP, ETH, USDT, ZEC, ATOM, USDC, BNB, AVAX, TRX, ALGO, TIA y XAUt. La primera estimación pública de Bitget el 24 de septiembre fue de $351.6 millones. La estimación aumentó tras identificar transferencias adicionales de Zcash y TRON.
XRP generó un desafío específico de recuperación porque no puede ser congelado por su emisor. Para el 26 de septiembre, aproximadamente $83 millones del XRP robado habían salido de las billeteras de almacenamiento del atacante. Cuando los activos salen de una dirección de depósito y entran en rutas de conversión o cross-chain, los investigadores deben seguir tanto los fondos como los servicios que los procesan.
El patrón de lavado dependió de la conversión rápida de stablecoins a ETH, seguida de intercambios a BTC. Los investigadores identificaron a THORChain como la ruta principal hacia BTC, con Chainflip, deBridge, SwapKit y Wasabi CoinJoin también presentes en la ruta de lavado. El 28 de septiembre, una billetera vinculada a un hacker intercambió aproximadamente 2,390 ETH, valorados en unos $6.3 millones, por 75.2 BTC mediante THORChain en lotes de aproximadamente 100 ETH.
La respuesta evidenció una tensión en la política entre infraestructura descentralizada y contención del incidente. THORChain rechazó la solicitud de Bitget de bloquear al hacker, afirmando que “una detención no equivale a un congelamiento selectivo de fondos específicos.” Chen respondió que “la descentralización es un principio de diseño, no un escudo para facilitar fondos robados conocidos.”
Esa interacción ilustra por qué la coordinación previa al incidente es fundamental. Los protocolos descentralizados pueden no tener la capacidad universal para identificar o congelar una transferencia individual sin afectar una ruta más amplia. Los exchanges centralizados, emisores de stablecoins, operadores de puentes y sistemas basados en intenciones aplican reglas de intervención diferentes. Un exchange que espere a que pase un exploit para entender esas reglas tendrá menos opciones durante las primeras horas de lavado.
¿Qué revela el hackeo de Bitget sobre el riesgo de terceros y de capa de autorización?
El hackeo de Bitget demuestra que la seguridad en los exchanges depende tanto del software de terceros, como de las credenciales internas, la presentación de transacciones y las políticas de riesgo, como de la custodia criptográfica. Bitget, Bybit, DMM Bitcoin y WazirX muestran un patrón recurrente: los atacantes comprometieron un proveedor confiable o una capa de aprobación para que una transacción maliciosa pareciera legítima para el proceso de firma o autorización.
| Incidente | Fecha | Capa comprometida | Pérdida o alcance reportado | Lección central |
|---|---|---|---|---|
| Bitget | 24 de septiembre de 2026 | Producto de seguridad de terceros y backend de billeteras | Aproximadamente $387.5 millones | Comandos de retiro falsificados bypassaron controles de riesgo |
| Bybit | 21 de febrero de 2025 | Máquina de desarrollo Safe{Wallet} y interfaz de firma | Aproximadamente $1.46 mil millones | Código malicioso alteró el entorno de aprobación de transacciones |
| DMM Bitcoin | Mayo 2024 | Empleado del proveedor de software de billetera y flujo de firma | Aproximadamente entre $305 y $308 millones | Compromiso del proveedor permitió actividad no autorizada en billeteras |
| WazirX | 18 de julio de 2024 | Contrato de billetera multisig y flujo de custodia | Aproximadamente $235 millones | Los signers aprobaron transacciones después de modificar el contrato |
| Coinbase | Revelado en mayo 2025 | Agentes de soporte en el extranjero y datos de clientes | Estimación de remediación entre $180 y $400 millones | La vulneración de datos de clientes puede generar una exposición operativa importante sin robo de claves |
El fallo frecuente no es la destrucción de criptografía en sí, sino la pérdida del contexto confiable en torno a una transacción. Un signer puede ver una solicitud válida, un destino conocido y un flujo de aprobación normal, mientras la instrucción subyacente ha sido reemplazada o manipulada.
Para los exchanges, esto requiere controles en varios puntos independientes:
- Aislamiento del proveedor: Los productos de seguridad de terceros no deben tener acceso innecesario a la generación de comandos de billeteras o credenciales privilegiadas.
- Compartimentación de credenciales: Las credenciales internas deben limitarse a funciones específicas, rotarse tras actividades sospechosas y no autorizar retiros multi-cadena en principio.
- Reconstrucción independiente de transacciones: La interfaz de aprobación debe obtener detalles de transacción de una fuente independiente, en lugar de confiar en el backend que creó la solicitud.
- Diversidad de políticas: Los retiros mayores deben pasar por reglas mantenidas por separado del backend de billetera operativo.
- Registro inmutable: Los registros deben almacenarse fuera del entorno comprometido e incluir creación, modificación, aprobación, firma y eventos de difusión.
- Transferencias canary: Las pequeñas transferencias de prueba no deben considerarse seguras solo porque estén por debajo de un umbral monetario. Repeticiones, destinos inusuales y patrones cross-chain deben correlacionarse.
- Apagado de emergencia: El exchange debe poder detener la firma y aislar servicios de billetera sin desconectar sistemas relacionados de trading y depósitos.
Bitget afirmó haber aislado servidores afectados, revocado y reprovisionado credenciales internas, y restructurado el acceso a sistemas sensibles. También declaró que la vulnerabilidad fue remediada. Esos pasos abordan la contención, pero una revisión duradera debe verificar si los mismos datos de transacción aún pueden manipularse antes de la aprobación.
Los servicios de auditoría de contratos inteligentes y seguridad de blockchain de Soken son relevantes en este límite de control porque la infraestructura de billeteras combina a menudo contratos inteligentes, servicios de firma, API backend, sistemas de gestión de claves y herramientas de terceros. Una evaluación centrada solo en código Solidity no probaría si un servicio comprometido puede alterar los datos que ve un firmante.
¿Qué tan efectivas fueron las medidas de recuperación y las atribuciones?
Las medidas de recuperación produjeron un reembolso confirmado limitado a partir del 29 de septiembre de 2026, mientras que la atribución seguía siendo probabilística y no oficial. Circle y Tether congelaron aproximadamente $339,100 en total, y NEAR Intents afirmó que su filtrado rechazó más de $50 millones en transferencias vinculadas a Bitget y congeló $503,000. Aún no se ha confirmado la recuperación de los fondos robados a Bitget.
Las acciones de recuperación reportadas fueron:
| Entidad o mecanismo de respuesta | Acción reportada | Cantidad |
|---|---|---|
| Circle y Tether | Congelaron USDC y USDT | Aproximadamente $339,100 en total |
| Saldos en stablecoins | USDT 239,113.50 y USDC 99,989.91 congelados | Incluidos en los $339,100 |
| NEAR Intents | Rechazaron transferencias vinculadas a Bitget | Más de $50 millones |
| NEAR Intents | Congelaron transferencias vinculadas a Bitget | $503,000 |
| Bitget | Ofreció recompensa por intervención y recuperación | 5% por congelamiento más 5% por recuperación |
La diferencia entre flujo rechazado y fondos recuperados es crucial. Un sistema de filtrado puede evitar que activos ingresen a una ruta específica sin devolver los fondos ya controlados por el atacante. De manera similar, las congelaciones por parte del emisor cubren solo saldos de stablecoins seleccionados, no XRP, ETH, BTC ni activos en infraestructura permissionless.
La atribución también requiere una redacción cuidadosa. Los análisis analíticos describieron el ataque como altamente probable vinculado a Corea del Norte e identificaron superposiciones con billeteras usadas en los hacks de Bybit y AFX Bridge. Otra evaluación describió una red tipo TraderTraitor, pero no atribuyó de forma definitiva el incidente de Bitget. Hasta el 29 de septiembre de 2026, ninguna agencia gubernamental había atribuido formalmente el ataque.
El patrón general es significativo. Contando a Bitget, el robo vinculado a Corea del Norte en 2026 superó los $1 mil millones en más de 50 incidentes. Una estimación del sector situó el total en $1.04 mil millones, haciendo de 2026 el segundo año más grande después de 2025, que se estimó en $1.68 mil millones.
El CEO de Bitget afirmó que el atacante probablemente era un grupo norcoreano. Esa declaración es una señal de riesgo operacional, no una atribución formal. Los equipos de seguridad deben emplear las superposiciones de billeteras disponibles y patrones de lavado para guiar la detección, manteniendo la incertidumbre en declaraciones públicas y procesos legales.
Bitget también afirmó que el 100% de los fondos de los usuarios estaban cubiertos por el Fondo de Protección de Bitget, que tenía 5,500 BTC, valorados en unos $464 millones en ese momento. La bolsa se comprometió a reponer el fondo a al menos $300 millones en una semana, utilizando reservas corporativas de más de $1.4 mil millones. Esos compromisos abordan la solvencia del cliente, pero no eliminan la necesidad de reparar la arquitectura de aprobación que permitió que los comandos de retiro pasaran.
El token BGB cayó aproximadamente entre 3% y 7% tras el incidente, llegando a un mínimo alrededor de $1.89 a $1.93 antes de recuperarse a aproximadamente $1.97. La reacción del mercado reflejaba por tanto un riesgo de confianza, además de la pérdida en billetera directa.
La respuesta de Bitget puede seguirse junto con investigaciones de incidentes más amplias a través del centro de investigación de seguridad de Soken, mientras que las organizaciones que revisan la gobernanza de exchanges pueden emplear auditoría técnica y soporte en respuesta a incidentes para probar los límites de credenciales, integridad de transacciones y controles de emergencia.
¿Qué deben cambiar los exchanges tras el exploit de Bitget?
Los exchanges deben tratar el exploit de Bitget como una falla en la integridad de autorización y probar todos los sistemas que generan, transforman, muestran, aprueban, firman o difunden un retiro. Proteger billeteras cold y claves privadas sigue siendo necesario, pero el incidente de Bitget demuestra que el riesgo de billeteras calientes y tibias también depende de metadatos confiables y rutas de aprobación independientes.
Un programa práctico post-incidente debe proceder en este orden:
- Reconstruir la ruta del comando. Mapear la ruta completa desde la solicitud de retiro hasta la difusión, incluyendo productos de terceros, cuentas de servicio, colas, APIs, sistemas de firma y conciliación.
- Revocar credenciales en general. Bitget revocó y reprovisionó credenciales internas. Otros exchanges deben identificar permisos heredados, cuentas de servicio inactivas y credenciales compartidas entre entornos.
- Separar construcción de transacciones de la aprobación de transacciones. La interfaz de aprobación debe verificar independientemente destino, activo, monto, cadena, nonce y clasificación de política.
- Preservar evidencia fuera de producción. Como el atacante eliminó rastros de comandos inyectados, los logs de auditoría deben replicarse en un entorno que los administradores no puedan reescribir.
- Volver a probar los umbrales de riesgo. Las transferencias de prueba de 0.184 ETH y 193 TRX pasaron por debajo de los umbrales. La detección debe combinar valor, novedad en destino, temporización, repetición, patrones cross-chain y contexto de credenciales.
- Ejercitar el proceso de apagado. Bitget aisló servidores, movió fondos restantes a cold y detuvo firma. Estas acciones deben ensayarse antes de un incidente y no improvisarse durante uno.
- Definir de antemano la escalación externa. Emisores de stablecoins, puentes, sistemas de intención, proveedores de analítica y autoridades deben incluirse en los manuales de respuesta a incidentes.
- Reabrir en fases controladas. La reapertura asset-por-asset permite monitoreo para validar cada ruta de billetera antes de reanudar retiros más amplios.
Un objetivo de control útil es simple: ningún sistema interno comprometido debe poder crear una solicitud de retiro, describírsela a un aprobador, satisfacer el motor de riesgo y activar la firma. Este objetivo aplica tanto si el exchange usa billeteras multisig, módulos de seguridad hardware, bóvedas de contratos inteligentes o infraestructura de custodia de terceros.
El incidente de Bitget también apoya una distinción más amplia entre seguridad en la custodia y seguridad en la autorización. La seguridad en la custodia pregunta si un atacante puede obtener claves. La seguridad en la autorización pregunta si el sistema puede ser inducido a aprobar una transacción incorrecta usando claves legítimas. Los exchanges que solo miden la primera categoría pueden reportar que las claves privadas permanecen seguras, mientras pierden control sobre los fondos que esas claves autorizan.
El cronograma de reapertura de Bitget, los compromisos del Fondo de Protección y la remediación de credenciales abordan la continuidad y protección del cliente. La siguiente cuestión técnica es si el exchange puede demostrar que los datos de transacción mostrados a los aprobadores ahora se generan y verifican de manera independiente del backend comprometido. Esa evidencia debe integrarse en cualquier informe público post-incidente.
La pérdida de Bitget, el drenaje multi-cadena de 17 transacciones y la recuperación limitada confirmada apuntan a la misma brecha de control: el software confiable y el contexto de transacción confiable deben tratarse como superficies de ataque. El siguiente paso concreto para un operador de exchange es trazar una retirada de extremo a extremo, luego intentar alterar sus datos de transacción mostrados sin cambiar la solicitud final de firma. Si las capas de monitoreo y aprobación no detectan esa discrepancia, la arquitectura de billeteras sigue expuesta.
Soken puede apoyar ese trabajo a través de evaluaciones de seguridad en exchanges y pruebas de penetración, enfocándose en la ruta de autorización que conecta las herramientas de terceros con las operaciones de billeteras caliente y tibia.