Contrariamente a las afirmaciones de Litecoin, un examen más detenido de sus registros de GitHub revela una vulnerabilidad no revelada previamente explotada en una reciente revisión de 13 bloques.
Una reorganización de la cadena de 13 bloques el viernes por la noche y el sábado rebobinó aproximadamente 32 minutos de actividad de la red después de que los atacantes utilizaran una vulnerabilidad en su protocolo Mimblewimble Extension Block (MWEB).
El error había permitido un ataque de denegación de servicio contra los principales grupos de minería, permitiendo que las transacciones MWEB no válidas pasaran por nodos que no se habían actualizado, antes de que la cadena válida más larga de la red las corrigiera.
¡Lanzamiento de Litecoin Core v0.21.5.4! Se recomienda a todos los usuarios que actualicen. Esta versión contiene importantes actualizaciones de seguridad. https://t.co/6vtrhdXi4c— Litecoin (@litecoin) 25 de abril de 2026
La Fundación dijo en las horas de la mañana asiática del domingo que el error se había solucionado por completo y que la red funciona con normalidad.
Sin embargo, investigadores destacados dicen que el repositorio GitHub del proyecto litecoin cuenta una historia diferente. El investigador de seguridad bbsz, que trabaja con el grupo de respuesta de emergencia SEAL911 para exploits criptográficos, publicó la línea de tiempo del parche extraída del registro de confirmación público.
Ahora que todo esto se ha hecho público en Litecoin GitHub, tenemos una mejor idea de la línea de tiempo y de lo que sucedió. En la era de los Mitos, esta línea de tiempo simplemente no funciona. La autopsia dice que un día cero provocó un DoS que dejó escapar un transmisor MWEB no válido. El inicio de sesión de git… https://t.co/zMMrheQLPP pic.twitter.com/O3DtdwV0rF— bbsz (@blackbigswan) 26 de abril de 2026
La vulnerabilidad de consenso que permitió la conexión inválida de MWEB fue reparada de forma privada entre el 19 y el 26 de marzo, aproximadamente cuatro semanas antes del ataque. La mañana del 25 de abril se solucionó otra vulnerabilidad de denegación de servicio.
Ambas correcciones se incorporaron a la versión 0.21.5.4 esa misma tarde, después de que el ataque ya hubiera comenzado.
"La autopsia dice que un día cero provocó un DoS que permitió que se filtrara una transacción MWEB no válida", escribió bbsz. "El registro de git cuenta una historia ligeramente diferente".
Un día cero se refiere a una vulnerabilidad desconocida para los defensores en el momento de un ataque.
El historial de confirmaciones de Litecoin muestra que la vulnerabilidad de consenso se conocía y se parcheaba de forma privada un mes antes del exploit, pero la solución no se había transmitido públicamente ni se había requerido a todos los grupos de minería.
Eso creó una ventana donde algunos mineros ejecutaron el código parcheado mientras que otros ejecutaron la versión aún vulnerable, y los atacantes parecen haber sabido cuál era cuál.
Alex Shevchenko, CTO del proyecto Aurora de la Fundación NEAR, planteó preocupaciones paralelas en un hilo.
Los datos de Blockchain mostraron que el atacante prefinanció una billetera 38 horas antes del exploit a través de un retiro de Binance, con la dirección de destino ya configurada para intercambiar $LTC por ETH en un intercambio descentralizado.
El ataque de denegación de servicio y el error MWEB eran componentes separados, argumentó Shevchenko, y el DoS estaba diseñado para desconectar los nodos de minería parcheados para que los no parcheados formaran la cadena que incluía las transacciones no válidas.
El hecho de que la red manejó automáticamente la reorganización de 13 bloques una vez que se detuvo el DoS sugiere que se estaba ejecutando suficiente hashrate en el código actualizado para eventualmente dominar el ataque, pero solo después de que la bifurcación sin parches se hubiera ejecutado durante 32 minutos.
Un éxito en Litecoin muestra cómo los ataques en varias redes difieren en cómo los mantenedores y desarrolladores de código reaccionan ante los exploits. Las cadenas más nuevas con conjuntos de validadores más pequeños y centralizados coordinan las actualizaciones a través de grupos de chat y pueden implementar parches en toda la red en cuestión de horas.
Las redes de prueba de trabajo más antiguas, como Litecoin y bitcoin, dependen de grupos de minería independientes que eligen cuándo actualizar, lo que funciona para cambios no urgentes pero crea una ventana de vulnerabilidad cuando un parche de seguridad debe llegar a todos antes de que un atacante aproveche la brecha.
La Fundación Litecoin no se ha referido públicamente al cronograma de GitHub hasta el domingo por la mañana.
No se ha revelado la cantidad de $LTC fijada durante la ventana de bloqueo no válido y el valor de los swaps completados antes de que la reorganización los revocara.