NEAR Intents reveló un exploit de aproximadamente $3.8M USDT en BNB Chain el 1 de octubre de 2026, rastreando el incidente hasta un bug en la interacción entre su infraestructura de depósito y retiro Omni y el contrato inteligente de NEAR Intents.
El incidente afectó principalmente la capa de interoperabilidad cross-chain en torno a NEAR Intents, en lugar de la capa 1 del NEAR Protocol. NEAR declaró que la red continuó produciendo bloques y procesando transacciones sin tiempo de inactividad, mientras NEAR Intents detuvo los servicios y parcheó la vulnerabilidad en el contrato. Hasta el 2 de octubre, no se había publicado la clase exacta del bug ni el componente que falló, pero los hechos disponibles apuntan a un límite crítico en la contabilidad del puente y la autorización de retiro.
Conclusión clave: El exploit de $3.8M en NEAR Intents evidencia la importancia de que la seguridad del puente garantice que cada liberación de activos corresponda a un depósito o débito real, único y previamente no consumido en cada cadena conectada. Un contrato inteligente parcheado es necesario, pero la defensa completa debe cubrir relayers, infraestructura del puente, controles de firma y lógica de reconciliación.
¿Qué ocurrió durante el exploit de NEAR Intents?
NEAR Intents perdió aproximadamente $3.8M en USDT en BNB Chain después de que atacantes explotaran un bug en la interacción entre la infraestructura de depósito y retiro Omni y el contrato inteligente de NEAR Intents. La fuga fue visible antes de la divulgación pública, mientras NEAR Intents detuvo los servicios, parcheó el problema en el contrato y anunció que los usuarios afectados serían compensados en su totalidad.
La actividad en la cadena indica que pequeños traslados de 10 USDT y 11 USDT dejaron el contrato drenado durante la tarde del 30 de septiembre, hora del Este de EE. UU. Estos pequeños traslados son coherentes con una fase de validación en la que un atacante prueba si un retiro, contabilidad o camino de liberación funciona como se espera antes de intentar extracciones mayores.
Luego, cinco transferencias mayores se realizaron desde las 23:54 UTC del 30 de septiembre hasta las 06:08 UTC del 1 de octubre. Dichas transferencias oscilaron desde aproximadamente 35,000 dólares hasta 1.5 millones de dólares. Un análisis de seguridad situó la pérdida en 3.865 millones de dólares desde una cartera caliente de BNB Smart Chain, mientras que el rastreo en la cadena descubrió aproximadamente 3.87 millones de USDT recolectados desde el contrato drenado.
NEAR Intents divulgó públicamente el exploit alrededor de las 12:53 UTC del 1 de octubre. El protocolo afirmó que sus servicios se detuvieron después de que SHIELD detectara actividad inusual, y la corrección en el contrato se implementó en aproximadamente una hora. Se esperaba que depósitos y retiros en 11 redes permanecieran inactivos durante unas 12 horas más, mientras se reparaba la infraestructura.
| Etapa del incidente | Fecha o hora | Evento concreto | Relevancia en seguridad |
|---|---|---|---|
| Primeras exploraciones | 30 de septiembre, tarde hora del Este de EE. UU. | Salieron 10 USDT y 11 USDT del contrato drenado en BNB Chain | Las transferencias pequeñas pueden revelar si un camino de liberación es explotable |
| Inicio del drenaje principal | 30 de septiembre, 23:54 UTC | Comenzó la primera de cinco transferencias mayores | El exploit pasó de una fase de exploración a la de extracción |
| Fin del drenaje principal | 1 de octubre, 06:08 UTC | Completó la quinta transferencia mayor | El período de extracción visible duró varias horas |
| Divulgación pública | 1 de octubre, alrededor de las 12:53 UTC | NEAR Intents informó que los servicios se detuvieron y que había un bug en la interacción del contrato de infraestructura y el contrato inteligente | La comunicación del incidente siguió a la fuga en cadena |
| Anuncio del plazo para devolución | 2 de octubre, 00:18 UTC | Se otorgó una ventana de 48 horas para devolver fondos | La fecha límite aproximada fue hasta el 4 de octubre, 00:18 UTC |
El activo afectado divulgado públicamente fue USDT en BNB Chain. Este alcance importa porque diferencia un incidente de aplicación e infraestructura del puente de un compromiso de la red base de NEAR o una falla general de todos los activos de NEAR Intents.
NEAR Intents había procesado más de $30B en alrededor de 35 blockchains, con un dashboard que mostraba $31.4B en volumen total hasta el 22 de septiembre. Sistemas con esa escala de enrutamiento no solo requieren contratos inteligentes seguros, sino que también exigen suposiciones de estado coherentes entre cadenas, operadores de puente, contratos de liquidación, sistemas de monitoreo y procedimientos de pausa operacional.
¿Cómo transfiere NEAR Intents normalmente activos entre cadenas?
NEAR Intents liquida los resultados cross-chain dirigidos por el usuario mediante su contrato intents.near, que mantiene un libro mayor de saldos de tokens depositados, actualiza esos registros cuando ocurren intercambios y libera tokens solo mediante rutas de retiro e infraestructura del puente. El exploit concernió el límite donde la infraestructura de depósito y retiro interactuaba con esa capa de liquidación.
Un usuario de NEAR Intents firma un resultado previsto en lugar de especificar directamente cada paso de ejecución. Los solucionadores y formadores de mercado compiten para cumplir ese resultado, y el resultado seleccionado se liquida en la cadena. Este modelo puede mejorar la ejecución cross-chain, pero también crea una superficie de confianza y verificación amplia: el libro de liquidación debe reconocer correctamente qué fue depositado, qué fue intercambiado, y qué puede ser retirado.
La documentación de NEAR Intents identifica tres sistemas de puente con diferentes modelos de confianza:
- Omni Bridge, operado por Near One.
- POA Bridge.
- HOT Bridge.
El diseño del HOT Bridge es especialmente relevante para el análisis del incidente porque el análisis público identificó que el contrato drenado en BNB Chain corresponde a la dirección del tesorero del HOT Bridge listada en la documentación de NEAR Intents, en lugar de la bóveda principal de NEAR Intents. Esa vinculación es análisis y no una determinación definitiva oficial de la causa raíz, y NEAR Intents no había confirmado cuál componente falló hasta el 2 de octubre.
En HOT Bridge, los contratos de locker en cada cadena compatible contienen activos nativos. Un contrato en NEAR crea omni-tokens que corresponden en relación uno a uno. Las firmas MPC de validadores autorizan depósitos y retiros, y el diseño especifica que cada nonce debe ser de un solo uso.
Esa arquitectura tiene varias propiedades de seguridad innegociables:
- Una liberación en BNB Chain debe corresponder a un bloqueo, débito o derecho liquidado real.
- Un mensaje de depósito no debe ser reproducible después de su ejecución.
- La aprobación del firmante debe estar vinculada exactamente a la cadena, activo, receptor, monto y nonce.
- Una solicitud de retiro no debe ser aceptada solo porque un componente externo afirme que es válida.
- El saldo del tesoro debe ser conciliado continuamente con el libro mayor y el estado autorizado del puente.
En nuestra experiencia auditando contratos inteligentes en Soken, los fallos más peligrosos en los puentes ocurren en los límites del sistema. Un contrato puede aplicar correctamente sus reglas locales y aún así liberar activos porque un mensaje upstream, un servicio off-chain, o una suposición contable en cruz de cadenas fue aceptada sin suficiente verificación independiente.
La lista de cadenas en pausa coincidió con la lista del HOT Bridge en la documentación de NEAR Intents: BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll y Plasma. Ethereum, Base, Arbitrum, Solana y Bitcoin no estaban en pausa. Las listas de cadenas coincidentes apoyan una hipótesis centrada en HOT Bridge, pero no confirman el componente vulnerable exacto.
¿Qué se sabe sobre el bug y qué aún se desconoce?
NEAR Intents confirmó que existió un bug en la interacción entre la infraestructura de depósito y retiro Omni y el contrato inteligente de NEAR Intents, pero hasta el 2 de octubre no divulgó el componente o clase de vulnerabilidad exacta. Cualquier afirmación de que el problema fue definitivamente una omisión en firma, falla en reproducción, error de contabilidad o compromiso de validadores iría más allá de la evidencia disponible.
La frase “interacción” es central. Sugiere que la vulnerabilidad no necesariamente fue un defectuoso simple y aislado en una función del contrato. Los sistemas cross-chain a menudo fallan cuando dos componentes razonables de manera individual no están en acuerdo sobre el significado, la finalización o la unicidad de una transición de estado.
Por ejemplo, un camino de liberación en un puente puede fallar si un componente off-chain produce una aprobación para un evento que nunca fue finalizado, si un contrato acepta un mensaje de retiro sin consumirlo permanentemente, o si la capa de contabilidad acredita un saldo que el locker subyacente no ha recibido realmente. Son mecanismos técnicos distintos, pero comparten la misma falla de seguridad: activos son liberados sin un activo bloqueado equivalente o débito válido.
El evento de NEAR Intents se asemeja a la forma general de varios incidentes mayores en puentes, aunque mantiene detalles confirmados distintos.
| Incidente | Fecha | Pérdida reportada | Forma de fallo confirmada |
|---|---|---|---|
| Wormhole | febrero 2022 | Aproximadamente $325M | Un bug en la verificación de firma permitió falsificar la aprobación de guardianes y acuñar 120,000 wETH sin colateral |
| Nomad | agosto 2022 | Aproximadamente $190M | Una actualización estableció la raíz confiable en cero, haciendo que cada mensaje fuera tratado como probado |
| Kelp DAO sobre LayerZero | abril 2026 | Aproximadamente $292M a $293M | Una configuración de verificador 1-de-1 permitió una quema fantasma para liberar fondos en Ethereum |
| Liquid Network | 6 de septiembre de 2026 | Aproximadamente $320M | Un bug en la caché de verificación de pruebas de rango permitió que L-BTC sin respaldo se peggedeara a BTC real |
| NEAR Intents | 1 de octubre de 2026 | Aproximadamente $3.8M | Un bug confirmado en la interacción de infraestructura de depósito y retiro Omni con el contrato inteligente de NEAR Intents |
Wormhole, Nomad, Kelp DAO y Liquid Network comparten un patrón común de fallo en la parte de liberación: un puente aceptó un crédito, prueba o mensaje que no mapeaba a un bloqueo o débito real. NEAR Intents aún no ha confirmado que el exploit del 1 de octubre siguió exactamente ese mecanismo, pero su contexto en el tesoro del puente hace que esta invariancia sea la primera que un análisis post-mortem debe abordar.
Ronin Bridge es un contraste útil. El incidente de marzo de 2022 involucró la compromisión de 5 de 9 claves de validadores. Esto es principalmente una falla en gestión de claves y umbral de validadores, más que la reconocimiento incorrecto por parte de un contrato de un crédito no respaldado como legítimo.
NEAR Intents se comprometió a añadir verificación formal en su proceso de lanzamiento. Los métodos formales son valiosos aquí al codificar directamente las invariantes del puente: una retirada válida no puede exceder un derecho liquidado, un mensaje de retiro no puede ejecutarse dos veces, y los liberaciones agregadas no pueden exceder el respaldo verificado en todo el sistema del puente.
Para protocolos que diseñan infraestructura similar, las revisiones de seguridad técnica deben probar todo el ciclo de depósito a liberación en lugar de considerar cada contrato, servicio o dominio de firmante como una frontera de seguridad separada.
¿Por qué las decisiones de respuesta y contención fueron relevantes?
NEAR Intents contuvo el incidente deteniendo los servicios tras que SHIELD detectó actividad inusual, parcheó la vulnerabilidad en el contrato en aproximadamente una hora, y pausó depósitos y retiros en 11 redes afectadas. La contención rápida limita una mayor extracción, pero la recuperación completa depende del rastreo, la escalada legal y demostrar que los flujos del puente reactivados cumplen con la invariancia de seguridad corregida.
La suspensión inmediata de servicios fue una respuesta adecuada ante la incertidumbre. Cuando un camino de retiro en cruz de cadenas puede estar produciendo liberaciones sin respaldo, continuar con la operación normal puede convertir un exploit limitado en un evento de agotamiento mayor de tesorería. La compensación granular, ensayada y observable para los usuarios legítimos, es clave en esta decisión.
NEAR Intents dijo que reportó el incidente a las autoridades y trabaja con socios de seguridad y análisis blockchain para rastrear los fondos y buscar recuperación. Los informes públicos indicaron que fondos robados se enviaron a KuCoin y se bridgieron a Bitcoin. Un rastreo separado encontró aproximadamente 1.5 M USDT moviéndose por el contrato de liquidación de CoW Protocol.
Un representante de NEAR Intents dio al explotador una ventana de 48 horas para devolver fondos, publicó direcciones de devolución en Bitcoin, BNB Chain y Solana, y no anunció ninguna recompensa. Hasta el 2 de octubre, no se había reportado devolución de fondos ni plan de reembolso.
El compromiso de compensación también es relevante. Illia Polosukhin, cofundador de NEAR, afirmó que todos los usuarios afectados serán indemnizados en su totalidad. Ese compromiso aborda el impacto en los clientes, pero no reemplaza la exigencia técnica de publicar un post-mortem preciso y un registro de remediación antes de reactivar las rutas afectadas.
Un paquete de post-incidente útil debe incluir:
- El componente vulnerable exacto y clase del bug.
- Los cambios en el contrato e infraestructura que eliminan el camino de explotación.
- Si alguna invocación, nonce, libro mayor, firmante o invariancia de reconciliación falló.
- Resultados de revisión independiente para la reparación.
- Un plan de restauración por cadena para BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll y Plasma.
- Reglas de monitoreo que detecten antes patrones similares de retiro anómalo.
El incidente también plantea cuestiones de gobernanza y operación más allá del código. La publicación de direcciones de devolución, rastreo de fondos, coordinación con exchanges, compensación a usuarios y la participación de las autoridades implican decisiones legales y de divulgación. Los equipos que preparan procedimientos de recuperación del puente deben alinear controles técnicos con el apoyo legal y de cumplimiento, especialmente en temas de custodia, reclamaciones de usuarios, sanciones y recuperación transfronteriza.
¿Qué cambios deben hacer los equipos de cross-chain tras el incidente de NEAR Intents?
Los equipos de cross-chain deben tratar cada retiro del puente como una prueba de conservación de valor: la liberación debe vincularse a un bloqueo o débito verificado, un mensaje único, un destino específico y una cantidad limitada. El incidente de NEAR Intents demuestra que la monitorización y las paradas de emergencia son imprescindibles, pero la prevención depende de hacer imposible autorizar estados inválidos entre componentes cruzados.
La primera tarea de ingeniería es definir la invariancia central del puente en términos comerciales y técnicos. Para un sistema estilo HOT Bridge, la invariancia no es simplemente “la firma MPC es válida”. Es más cercano a: “esta retirada exacta está autorizada una sola vez, para este activo y receptor, después de un depósito finalizado y no gastado o débito en el libro mayor correspondiente.”
Esa invariancia debe probarse frente a diferentes modos de fallo:
- mensajes duplicados y reutilización de nonce;
- identificadores de cadena no coincidentes;
- direcciones de token o conversiones de decimales no coincidentes;
- aprobaciones de firmantes obsoletas;
- fallos parciales en infraestructura;
- saldos inconsistentes en libro mayor y locker;
- transiciones de pausa de emergencia;
- intentos de reproducción tras actualizaciones o migraciones de contrato.
En segundo lugar, los protocolos deben separar la detección de la confianza. SHIELD detectó actividad inusual durante el evento de NEAR Intents, ayudando a activar la contención. Sin embargo, la monitorización no debe ser la única barrera entre un error contable y la pérdida de la tesorería. Un sistema de monitoreo debe identificar comportamientos sospechosos una vez que comienzan. Las reglas de verificación de contratos y puentes deben rechazar movimientos inválidos antes de que la transferencia sea ejecutable.
En tercer lugar, los equipos deben construir reconciliaciones que comparen los bloqueos en la cadena de origen, los créditos en el ledger de liquidación, las liberaciones en la cadena de destino y las autorizaciones pendientes de retiro. Una discrepancia debe reducir automáticamente los límites o detener la ruta afectada. Este control es especialmente importante para caminos de billeteras calientes y tesorería, donde una transacción con aspecto válido puede mover activos líquidos rápidamente.
En cuarto lugar, la verificación formal debe enfocarse en propiedades relevantes para el modelo de negocio del puente, no solo en seguridad aritmética. La promesa de NEAR Intents de incorporar verificación formal es acertada si cubre transiciones de estado en depósitos, liquidaciones, creación de mensajes del puente y ejecución de retiros. Una prueba formal de una función del contrato no es suficiente si un componente externo puede alimentarle una premisa incorrecta pero aceptada.
El centro de investigación de Soken analiza modos recurrentes de fallos en contratos y seguridad de protocolos, incluyendo la diferencia entre una verificación local y una garantía de seguridad sistemática. Para los equipos de puente, la lección práctica es clara: el alcance de auditoría debe incluir contratos, formatos de mensajes, políticas de firmantes, controles operativos, telemetría del monitoreo y procedimientos de recuperación.
NEAR Intents ahora debe convertir su promesa de post-mortem en un plan de restauración verificable: identificar la interacción fallida, demostrar por qué el camino arreglado no puede liberar USDT sin respaldo, y probar independentemente cada ruta de HOT Bridge reactivada. Los equipos que operan infraestructura cruzada similar deben comenzar mapeando cada autorización de retiro a su bloqueo o débito subyacente, y luego verificar si esa vinculación sobrevive a reintentos, retrasos, actualizaciones y ordenamientos adversariales de mensajes.