Por Canuto  

Un fallo en el sistema que registraba los saldos de las subcuentas de Arcus DEX permitió retirar fondos que el atacante nunca había depositado. Arcus Labs afirma que cubrirá los USD $2,23 millones perdidos y que sus controles bloquearon otros USD $3 millones en retiros intentados.
***

  • El atacante aprovechó un error contable para retirar aproximadamente USDG 2.234.391, según el informe del incidente.
  • Arcus Labs aseguró que usó fondos de su tesorería corporativa para cubrir la pérdida y que otros usuarios no fueron afectados.
  • Un límite de retiro bloqueó transacciones por otros USD $3 millones, mientras Arcus suspendió y luego reanudó los retiros tras corregir la vulnerabilidad.

 


 

El intercambio descentralizado (DEX) Arcus sufrió un exploit que permitió a un atacante retirar fondos que no había depositado, luego de manipular los saldos registrados en una de las subcuentas de la plataforma. El incidente ocurrió el 9 de noviembre de 2026 y provocó una pérdida de USD $2,23 millones, pero los controles de retiro bloquearon otros USD $3 millones en transacciones intentadas.

Arcus Labs afirmó que cubrió el déficit con fondos de la tesorería de la empresa y que los saldos, las posiciones de trading y las órdenes de los demás usuarios no resultaron afectados. El caso, reportado por CoinEdition, se originó en un error de contabilidad relacionado con transferencias entre subcuentas, no en el robo de una clave privada.

Un saldo manipulado permitió retirar fondos que no existían

El ataque se dirigió al mecanismo que administra las transferencias entre subcuentas de Arcus DEX. Estas cuentas permiten separar fondos de trading bajo una billetera principal, pero una falla contable hizo posible alterar el saldo que el sistema mostraba en una de ellas y aparentar que había más dinero disponible del que realmente se había depositado.

Con el saldo incorrecto como referencia, el sistema aprobó retiros contra fondos reales de la plataforma. Según el informe del incidente, el atacante consiguió retirar aproximadamente USDG 2.234.391 antes de que Arcus suspendiera los retiros; el ataque involucró una cuenta recién creada, aunque la información publicada no atribuye una identidad a quien la controlaba.

La diferencia entre un saldo registrado y el dinero efectivamente disponible fue central para el exploit. En vez de obtener acceso a la billetera de otro cliente, el atacante aprovechó la forma en que Arcus calculaba los fondos de una cuenta y logró que el proceso de retiro aceptara una cifra que no correspondía con los depósitos reales.

El informe describió el incidente como un error de contabilidad, no como una vulneración de claves privadas. Esa distinción delimita el mecanismo del ataque: el problema reportado estaba en la lógica con la que la plataforma reflejaba y validaba saldos, y no en la toma de control de la billetera de un usuario ajeno.

Los límites de retiro redujeron el daño potencial

El atacante también intentó retirar otros USD $3 millones, pero un límite de retiro en cadena bloqueó esas transacciones. Por ese control, la pérdida confirmada se mantuvo en USD $2,23 millones, en lugar de alcanzar los USD $5,23 millones que habrían estado en riesgo si ese segundo conjunto de retiros hubiera prosperado.

Arcus suspendió los retiros a las 11:07 p. m., hora del Este, del 9 de noviembre. La compañía indicó que corrigió la vulnerabilidad unos 30 minutos después y que reanudó los retiros a las 4:26 a. m. del 10 de noviembre, después de aplicar el arreglo al sistema afectado.

Además de detener temporalmente los retiros, Arcus bloqueó las direcciones vinculadas al atacante para operar, transferir fondos y retirar dinero. La empresa también dijo que revisó el código con socios de seguridad, medidas que acompañaron la corrección del fallo y la vuelta a la actividad normal de trading y retiros.

El límite de retiro no evitó la pérdida inicial, pero sí acotó el monto que pudo salir de la plataforma durante el ataque. El episodio muestra por qué un control de ese tipo puede funcionar como barrera de contención cuando una falla de software permite que el sistema procese movimientos que no reflejan los saldos reales.

Arcus Labs cubrirá la pérdida con fondos corporativos

Arcus Labs afirmó que utilizaría fondos de la tesorería corporativa para cubrir la pérdida total de USD $2.234.391. La empresa sostuvo que solo una cuenta resultó afectada y que los fondos y actividades de trading de los demás usuarios permanecieron seguros, por lo que el impacto financiero inmediato no se trasladaría a otros clientes.

La cobertura anunciada por la compañía responde al déficit generado por los retiros que sí se completaron. No equivale a que el exploit no haya tenido consecuencias para Arcus: la plataforma reconoció una salida de fondos, aunque aseguró que sus recursos corporativos asumirían esa pérdida y que los controles impidieron un drenaje mayor.

Arcus también compartió la dirección de la billetera del atacante y pidió a exchanges y otros proveedores de servicios que marcaran los fondos vinculados con ella. Esa solicitud busca alertar a intermediarios que pudieran detectar o recibir activos relacionados con la dirección señalada, aunque el informe no confirma que esas empresas hayan tomado medidas.

Por separado, circularon reportes sobre una posible propuesta para que el atacante devolviera el 90% de los fondos a cambio de una recompensa del 10%, con fecha límite del 13 de noviembre. Sin embargo, esa oferta apareció en cuentas de alertas de seguridad y no fue confirmada en el informe oficial del incidente de Arcus, por lo que no debe presentarse como un acuerdo formal de la empresa.

El incidente pone el foco en la contabilidad de las plataformas DeFi

El caso de Arcus recuerda que los riesgos de seguridad en una plataforma cripto no se limitan a la exposición de claves privadas o a fallas en contratos inteligentes. Un error en el cálculo o la validación de los saldos también puede abrir una vía para retirar activos, si la plataforma confía en un registro incorrecto al autorizar una operación.

La vulnerabilidad descrita afectó la relación entre el saldo mostrado y los fondos que podían retirarse desde una subcuenta. Esa diferencia es especialmente relevante en servicios que ofrecen múltiples cuentas de trading o distintas opciones de colateral, porque sus sistemas deben mantener consistencia entre los movimientos internos y los activos disponibles para retiros.

Los datos divulgados por Arcus no indican que las posiciones, órdenes o saldos de los demás usuarios hayan sido alterados. También señalan que la empresa corrigió la falla, restringió las direcciones identificadas y revisó el código con socios de seguridad; el reporte no detalla, en cambio, una auditoría independiente ni la identidad del atacante.

Tras la corrección, los retiros y las operaciones de trading volvieron a la normalidad, según la información difundida por la plataforma. El desenlace inmediato combina una pérdida reconocida, un compromiso de cubrirla con fondos corporativos y controles que limitaron el monto retirado, aunque la oferta de recompensa para recuperar activos sigue sin confirmación oficial.


Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA




ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín