Por Canuto  

Una vulnerabilidad de XCM corregida en el código meses antes del lanzamiento de dotUSD seguía presente en los sistemas afectados. La pérdida estimada para el Tesoro de Polkadot rondó los USD $1,3 millones, mientras Parity sostuvo que ningún usuario perdió fondos.
***

  • Parity dijo que el error se corrigió en junio, pero el parche no llegó a los runtimes de producción afectados antes del ataque de octubre.
  • El atacante reanudó la explotación con un relayer propio después de que Snowfork detuviera sus relayers y antes de que entrara en vigor la actualización correctiva.
  • La operación distorsionó los precios del pool DOT/dotUSD; el Tesoro era su único proveedor de liquidez y absorbió las pérdidas estimadas.

Polkadot perdió cerca de USD $1,3 millones por una falla corregida que no llegó a producción

El Tesoro de Polkadot perdió cerca de USD $1,3 millones después de que un atacante aprovechara una vulnerabilidad vinculada al sistema de mensajería entre cadenas de la red. Según la revisión del incidente de XCM, la falla ya había sido corregida en el código en junio de 2026, pero el arreglo no llegó a los sistemas de producción afectados antes de la explotación, que se extendió del 24 al 26 de octubre.

El ataque impactó el mercado de dotUSD, una stablecoin descentralizada lanzada en octubre bajo la gobernanza de la red. Parity afirmó que ningún usuario perdió fondos y que dotUSD continuó totalmente respaldada por USDT, pero reconoció que el Tesoro, único proveedor de liquidez del pool afectado, soportó pérdidas por operaciones a precios distorsionados.

Una falla corregida que no llegó a los sistemas afectados

La brecha no surgió de un error recién introducido por el lanzamiento de dotUSD, sino de una vulnerabilidad previa en XCM, el mecanismo que permite intercambiar mensajes y activos entre cadenas. Parity indicó que su equipo identificó y corrigió el problema en la base de código durante junio de 2026, aunque la reparación quedó fuera de los runtimes de producción que luego resultaron vulnerables.

La compañía explicó que el parche se perdió durante el corte de la versión stable-2606, por lo que la existencia de una corrección en el repositorio no garantizó que el software desplegado incorporara esa defensa. La diferencia entre corregir código y desplegarlo en las redes activas fue decisiva: el sistema seguía expuesto cuando comenzó la explotación en octubre.

Parity había clasificado inicialmente la vulnerabilidad como de severidad media. La evaluación no contempló cómo el fallo podía interactuar con dotUSD, que aún no había sido lanzada, y la empresa elevó su clasificación a crítica después de que el ataque demostrara el potencial de daño financiero.

La secuencia también planteó preguntas sobre cómo evaluar riesgos cuando cambian las funciones de una red. Una vulnerabilidad que parecía tener un impacto limitado antes de la llegada de un nuevo activo puede adquirir consecuencias distintas cuando ese activo empieza a operar en un pool de liquidez, como ocurrió con dotUSD.

Cómo la explotación alteró el mercado de dotUSD

Según la revisión de incidentes de Parity, el atacante manipuló el sistema de mensajería entre cadenas de Asset Hub para reducir la oferta registrada de dotUSD sin retirar tokens de las cuentas de sus titulares. Esa diferencia entre la oferta contabilizada y los saldos existentes alteró la información que utilizaba el mercado para reflejar el valor del activo.

El desajuste distorsionó los precios en el pool de liquidez DOT/dotUSD. Con cotizaciones artificiales, los operadores pudieron intercambiar dotUSD por DOT a tasas que no representaban de manera fiable la situación del activo, y el Tesoro de Polkadot, como único proveedor de liquidez de ese pool, absorbió el costo de esas operaciones.

La pérdida estimada para el Tesoro rondó los USD $1,3 millones, pero Parity no pudo establecer si la persona que explotó la vulnerabilidad también obtuvo ganancias de las operaciones de arbitraje posteriores. La distinción importa porque el daño contabilizado por el fondo común no identifica, por sí solo, quién recibió los beneficios asociados a los precios alterados.

La empresa sostuvo que los usuarios no perdieron fondos y que dotUSD seguía totalmente respaldada por USDT. Además, el atacante no modificó los saldos individuales de las cuentas al reducir la emisión registrada, de modo que la discrepancia afectó el cálculo de la oferta y el funcionamiento del pool, no la cantidad de tokens anotada en cada billetera.

El apagado de emergencia y las actualizaciones

El 24 de octubre, Snowfork detuvo sus propios relayers de consenso después de detectar actividad sospechosa, lo que interrumpió temporalmente la explotación a través de su infraestructura. Sin embargo, esa medida no podía bloquear por completo el sistema: Snowbridge permite que participantes independientes operen relayers sin autorización central, por lo que el atacante pudo recurrir a uno propio.

El 26 de octubre, el atacante reanudó la actividad con su relayer y volvió a explotar la falla unas seis horas antes de que entrara en vigor la actualización correctiva. El episodio mostró los límites de una respuesta que detiene los servicios de un operador, pero no puede impedir que otro participante continúe ejecutando el proceso en una arquitectura abierta.

La actualización de runtime 2.5.1 incorporó la corrección de XCM y se aplicó en cadena el 26 de octubre, según el informe de Parity. Una segunda versión, la 2.5.2, se promulgó el 30 de octubre para conciliar la oferta registrada de dotUSD con los saldos de las cuentas existentes, sin cambiar los saldos individuales.

Parity también señaló que la segunda actualización resolvió un problema separado que había alterado Snowbridge. La liquidez restante del pool afectado fue rescatada y los dotUSD recuperados regresaron al Tesoro, pero esas acciones no revirtieron las pérdidas provocadas por las operaciones realizadas con precios artificiales.

La divulgación previa y los cambios anunciados

El 20 de octubre, un investigador que había reportado originalmente la vulnerabilidad publicó en un foro un comentario que hacía referencia a la corrección del código de junio. Parity dijo que el investigador eliminó la publicación después de recibir un aviso de que infringía las reglas de su programa de recompensas por errores, y planteó que el comentario pudo haber ayudado a los atacantes a localizar el fallo.

Ese vínculo, sin embargo, no está demostrado: la empresa describió la publicación como una posible fuente de información, no como una explicación confirmada de cómo el atacante encontró la vulnerabilidad. La identidad de quien se benefició del eventual arbitraje también quedó sin resolver, según la información divulgada sobre el incidente.

Parity reconoció que sus procesos de seguridad no tuvieron suficientemente en cuenta los riesgos que nuevas funciones podían introducir en vulnerabilidades previamente reportadas. La empresa dijo que revisará las evaluaciones de fallas, reforzará las comprobaciones de despliegue y ampliará la vigilancia de movimientos inusuales en la emisión de activos.

Entre las medidas anunciadas también figura el perfeccionamiento de un marco automatizado de seguridad basado en inteligencia artificial, destinado a detectar antes del desarrollo cambios de código potencialmente explotables. Parity indicó, además, que volverá a examinar vulnerabilidades reportadas con anterioridad para identificar riesgos que puedan surgir de funciones como dotUSD, una revisión que aborda tanto la prevención como el proceso de llevar los parches desde el código hasta la red activa.


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

Artículos Relacionados