~$418M perdidos: Exploits de Bitget y NEAR Intents

Durante las últimas dos semanas (21/09/2026 - 04/10/2026), se registraron 8 incidentes de seguridad en blockchain que causaron pérdidas totales estimadas de aproximadamente $418.4M.

Fecha	Incidente	Tipo	Pérdida Estimada
2026/09/23	Meter Passport	Falla de Validación de Bloques	~$2.3M
2026/09/24	Payy Network	Sospecha de Falla de Solidez del Sistema de Pruebas	~$1.9M
2026/09/24	Limit Break	Validación Inadecuada de Calldata	~$7.7M
2026/09/24	Duelbits	Causa Raíz No Divulgada	~$7M
2026/09/24	Bitget	Vulnerabilidad en Producto de Seguridad de Terceros	~$387.5M
2026/09/27	DYORSwap	Verificación Insuficiente de Configuración de Red	~$2.1M
2026/09/30	NEAR Intents	Validación Inadecuada de Reembolsos y Ausencia de Reversión	~$3.9M
2026/10/04	Unnamed Base Vault	Control de Acceso Inadecuado	~$6M

Razones de la selección

Bitget: El incidente representa la mayor parte de las pérdidas del período y traza un compromiso fuera de cadena mediante comandos de retiro falsificados hacia transferencias válidas en cadena, sin que se haya comprometido una clave privada ni un contrato inteligente.
NEAR Intents: Una falla en la validación de reembolsos y la ausencia de una reversión de estado convirtieron la resolución fallida de depósitos entre cadenas en saldos internos sin respaldo que pudieron pasar por la vía normal de retiro.

Bitget

El 24 de septiembre, aproximadamente $387.5M salieron de partes de la infraestructura de billeteras "hot" y "warm" de Bitget en Ethereum y otras redes EVM, XRP Ledger, Zcash y TRON. Las transacciones en cadena llevaban firmas de billetera válidas. Bitget declaró que el atacante explotó una vulnerabilidad en un producto de seguridad de terceros, obtuvo credenciales de acceso a la intranet y falsificó comandos de retiro, mientras que las claves privadas y las billeteras frías permanecieron seguras[1][2].

Resumen del Incidente

Los informes de investigación independientes añaden detalles a la ruta del ataque sin nombrar los dos productos de seguridad afectados. SlowMist rastreó la actividad maliciosa más temprana en el Producto A hasta el 31 de agosto e identificó un día cero que afectaba a un servicio en un nodo. Mandiant encontró acceso privilegiado a dos dispositivos de seguridad, una web shell y una conexión de mando y control en el Producto B, así como movimiento lateral hacia el servidor de tareas de billeteras en producción.

Por separado, SlowMist descubrió que el atacante usó la identidad de un empleado interno para acceder a la plataforma de gestión del Producto B. Los investigadores también recuperaron una herramienta de retiro personalizada que falsificaba parámetros de control de riesgo, construía solicitudes de retiro e invocaba el proceso de retiro. Cómo se movió el atacante entre todos los sistemas involucrados permanece bajo investigación. Las cadenas públicas registraron las transferencias finales firmadas, no estas operaciones previas.

Los registros en cadena muestran que los primeros movimientos fueron 93 TRX y, 11 segundos después, 0.84 ETH a las 18:31 UTC. La cronología actual de Bitget registra la detección de la reconciliación a las 19:05 UTC y la activación de su respuesta de emergencia de más alto nivel a las 19:14 UTC[1]. Una transferencia separada de 20.59M TRX llegó a la dirección de TRON controlada por el atacante a las 19:16 UTC; Chen describió 17 transferencias mayores en otras ocho redes que sumaron aproximadamente $361M[3]. La contención comenzó a las 19:40 UTC, y los servicios de retiro y firma de billeteras se cerraron a las 21:44 UTC[1].

Estado de los Fondos y Respuesta de la Comunidad

A las 16:35:28 UTC del 29 de septiembre, el rastreador de tenencias oficial de Bitget reportó $322.67M en tenencias actuales del atacante, aproximadamente $632,700 congelados, $312,500 en stablecoins congelables por el emisor y $55.87M en tránsito o aún en análisis. Su vista de direcciones por separado mostró saldos concentrados en BTC ($288.51M), ZEC ($28.91M) y ETH ($7.17M); esa vista utiliza un alcance de clasificación diferente al del resumen general.

Binance compartió inteligencia y apoyó el rastreo de fondos, mientras que Bybit actualizó LazarusBounty y ofreció asistencia[4][5]. Los proveedores de infraestructura tomaron decisiones diferentes. Bitget pidió a THORChain que negara el servicio a las direcciones del atacante que había listado, argumentando que la descentralización no debería proteger la circulación de fondos robados conocidos[6]. THORChain rechazó el uso de listas negras selectivas y afirmó que sus controles podrían detener una actividad más amplia o una ruta de cadena completa, pero no una dirección o transacción individual[7].

NEAR Intents informó que SHIELD identificó y bloqueó más de $50M en flujos intentados vinculados al atacante, después de filtrar duplicados. Aproximadamente $503,000 fueron congelados durante la ejecución y cerca de $166,000 lograron pasar; la cifra de $50M corresponde a flujo intentado, no a un monto congelado o recuperado[8]. El rastreador clasificó posteriormente $293,507 como congelados en NEAR Intents, y las fuentes públicas no concilian la diferencia.

Lecciones Aprendidas

El atacante ingresó a través de productos de seguridad de terceros, alcanzó el servidor de tareas de billeteras y convirtió solicitudes de retiro falsificadas en transacciones válidamente firmadas. Cualquier producto de terceros con ese alcance pertenece al perímetro efectivo de seguridad de activos: las instituciones deben aislarlo, restringir identidades y privilegios, monitorear su comportamiento y verificar de forma independiente la intención de retiro antes de firmar.
La autoridad de recuperación estaba fragmentada entre exchanges, emisores de stablecoins, servicios de enrutamiento y protocolos base, por lo que ningún participante podía gestionar la respuesta por sí solo. La institución afectada necesita compartir rápidamente direcciones y datos de transacciones verificados, mientras que los proveedores de infraestructura y los equipos de seguridad coordinan el rastreo, la congelación, el filtrado de transacciones y la recuperación dentro de sus limitaciones técnicas y de gobernanza.
Para conocer los controles preventivos derivados de este incidente, consulte Bitget's $387.5M Off-Chain Breach: Beyond Keys and Contracts, que desarrolla un marco de defensa en profundidad para el acceso privilegiado, la intención de retiro, el monitoreo de flujo de activos y la respuesta de emergencia.

NEAR Intents

Entre el 30 de septiembre y el 1 de octubre, NEAR Intents perdió aproximadamente $3.87M después de que una falla en la validación de reembolsos y una ausencia de reversión de estado en intents.near crearan un saldo interno sin el respaldo de activo correspondiente. El atacante utilizó ese saldo para obtener firmas de retiro válidas de HOT MPC y liberar USDT real de la bóveda del protocolo en BNB Chain[9][10].

Antecedentes

NEAR Intents es un sistema de ejecución de intenciones sobre NEAR. Su contrato principal, intents.near, mantiene omni-activos, registra los saldos internos de los usuarios y procesa intercambios y retiros de activos en función de intenciones firmadas.

Para un depósito entre cadenas, una bóveda en la cadena de origen bloquea el activo real. Omni crea el omni-activo correspondiente en NEAR y lo transfiere a intents.near, que acredita el saldo interno del usuario.

Para un retiro, intents.near solicita a Omni que destruya el omni-activo correspondiente y cree un registro de retiro. HOT MPC verifica ese registro y emite una firma. La bóveda de la cadena de destino verifica la firma antes de liberar el activo real. Este proceso requiere que los saldos internos registrados por intents.near permanezcan respaldados por los omni-activos que el contrato realmente posee.

Análisis de la Vulnerabilidad

La vía de depósito acreditaba el saldo interno del receptor antes de que la transferencia entre contratos se hubiera resuelto por completo. Durante la resolución, resolve_deposit_internal() limitaba el requested_refund, controlado por el receptor, mediante el saldo total del receptor para ese token, pero no mediante deposited, el monto efectivamente transferido en el depósito que se estaba resolviendo. El saldo total solo mostraba lo que la cuenta podía pagar; deposited definía lo que esta transferencia en particular podía reembolsar. Sin ese segundo límite, un receptor con un saldo previo elevado podía solicitar un reembolso muy superior al depósito actual[10].

En un depósito por lotes con muchos identificadores de token largos, los valores de reembolso incorrectos ampliaban el MtBurnEvent serializado. La ruta check_refund().unwrap_or_panic_display().emit() entraba entonces en pánico cuando el evento superaba el límite total de longitud de registro (log) de NEAR, provocando que el recibo de mt_resolve_deposit fallara.

El saldo interno ya había sido acreditado en un recibo anterior. El pánico revirtió los intentos de deducción de saldo y de suministro del recibo de la función de retorno (callback), pero no revirtió ese crédito anterior. Omni devolvió entonces los activos transferidos al remitente, dejando al atacante con un saldo interno retirable que ya no coincidía con los omni-activos que poseía intents.near. La vulnerabilidad combinó una falla en la validación de reembolsos con la ausencia de reversión de estado a lo largo de la secuencia asíncrona de recibos.

Análisis del Ataque

La siguiente reconstrucción se basa en información disponible públicamente[11].

Fase 1: Crear un Saldo Interno Sin Respaldo en NEAR

Paso 1: El atacante depositó 10 USDT a través de la bóveda Omni/HOT de BNB Chain, otorgando a la cuenta receptora maliciosa un saldo de omni-activo distinto de cero en NEAR.
Paso 2: El atacante llamó a mt_batch_transfer_call() en v2_1.omni.hot.tg. En mt_on_transfer(), intents.near primero acreditó al receptor mediante deposit(), luego notificó al receptor malicioso y transmitió su respuesta a mt_resolve_deposit().
Paso 3: El receptor malicioso devolvió un requested_refund muy superior al depósito actual. Dado que la validación usaba el saldo total del token del receptor como su límite, el valor anómalo avanzó hacia el procesamiento del reembolso.
Paso 4: A través de las entradas por lotes, los valores de reembolso sobredimensionados hicieron que el MtBurnEvent serializado superara el límite total de longitud de registro de NEAR. La función de retorno mt_resolve_deposit entró en pánico, lo que revirtió sus intentos de deducción de reembolso, pero no el crédito interno ya confirmado por el recibo anterior. Omni devolvió los activos transferidos, mientras que el saldo acreditado permaneció disponible en intents.near. Repetir esta secuencia creó un saldo sin respaldo que el atacante podía retirar.

Fase 2: Retirar Activos Reales de la Bóveda de BNB Chain

Paso 5: A las 18:57 y 20:05 UTC del 30 de septiembre, el atacante usó autorizaciones válidas de HOT MPC para probar la bóveda de BNB Chain con retiros de 10 USDT y 11 USDT. La primera transacción de prueba confirmó que la bóveda aceptaba la autorización previa.

Paso 6: Desde las 23:54 UTC del 30 de septiembre hasta las 06:08 UTC del 1 de octubre, el atacante realizó cinco retiros mayores de 800,000 USDT, 1.2M USDT, 1.5M USDT, 330,000 USDT y 35,000 USDT. Estas transacciones liberaron un total de 3.865M USDT de la bóveda.

Conclusión

NEAR Intents fue explotado a través de una validación de reembolsos incorrecta y una ausencia de reversión tras el fallo en la resolución del depósito. El atacante utilizó solicitudes de reembolso sobredimensionadas para preservar el crédito interno después de que los activos subyacentes hubieran sido devueltos, y luego usó ese saldo sin respaldo para solicitar retiros. Omni creó los registros de retiro correspondientes, HOT MPC los firmó y la bóveda de BNB Chain liberó USDT real.

El procesamiento de reembolsos debería limitar el reembolso de cada token al monto del depósito que se está resolviendo. El protocolo también debería hacer que el crédito de saldo y la resolución sean atómicos cuando sea posible, o aplicar una reversión compensatoria garantizada tras un fallo. Antes de emitir firmas de retiro, debería conciliar los saldos internos agregados con las tenencias reales de omni-activos y pausar los retiros ante cualquier discrepancia. La generación de eventos también debe estar acotada, de manera que un registro sobredimensionado no pueda interrumpir una ruta de resolución crítica para el estado.

Referencias

[1] https://www.bitget.com/academy/bitget-security-incident-what-happened-timeline-impact-response

[2] https://x.com/GracyBitget/status/2104515761691939026

[3] https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[5] https://x.com/benbybit/status/2103328213141508335

[6] https://x.com/GracyBitget/status/2103812967066439817

[7] https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[8] https://x.com/GracyBitget/status/2104602301503816040

[9] https://x.com/near_intents/status/2105642219357241796

[10] https://github.com/near/intents/pull/362

[11] https://x.com/Phalcon_xyz/status/2105680009687957909

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento normativo en cripto. Desarrollamos productos y servicios que ayudan a nuestros clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones de AML/CFT, a lo largo de todo el ciclo de vida de los protocolos y plataformas.

BlockSec ha publicado múltiples artículos de investigación sobre seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares, y ha protegido miles de millones de dólares en criptomonedas.