Litecoin afrontó recientemente uno de sus incidentes técnicos más graves relacionados con la funcionalidad Mimblewimble Extension Blocks (MWEB), después de que una falla de validación permitiera a un atacante generar un peg-out inflado de aproximadamente 85,034 LTC.
El problema se rastreó hasta una falla en la verificación a nivel de conexión de bloques, en la que los metadatos de entrada de MWEB no coincidían correctamente con el UTXO subyacente que se estaba gastando.
Si bien el incidente sacudió brevemente la confianza en la capa de extensiones, en última instancia se contuvo gracias a la respuesta coordinada de los mineros y a correcciones rápidas del protocolo.
Cómo se desarrolló la explotación de MWEB
Según un postmortem publicado por Litecoin, la explotación comenzó en marzo de 2026 en la altura de bloque 3,073,882, cuando un atacante explotó con éxito la brecha de validación.
Al manipular los datos de entrada de MWEB, el atacante hizo que una entrada pequeña pareciera justificar una salida mucho mayor durante el procesamiento del peg-out.
En realidad, el valor subyacente de la entrada era de solo alrededor de 1–2 LTC, pero el sistema lo aceptó incorrectamente como respaldo válido para más de 85,000 LTC.
Esto no fue un problema estándar a nivel de monedero ni de capa de transacción. En cambio, se originó en la forma en que se validaban los bloques MWEB durante la conexión a la cadena.
Si bien el mempool y las capas de construcción de transacciones funcionaron correctamente, el paso final de verificación a nivel de consenso no llegó a validar completamente la integridad de los metadatos de MWEB frente a las salidas referenciadas.
Una vez detectado el peg-out anómalo, los mineros identificaron rápidamente la inconsistencia e iniciaron acciones coordinadas para evitar su propagación.
Las salidas sospechosas se aislaron y una parte de los fondos se congeló a nivel de protocolo para impedir su movimiento a través de la red.
Contención, recuperación y coordinación entre mineros
Tras la detección, desarrolladores y las principales pools de minería pasaron a modo de respuesta de emergencia.
Las pools de minería, incluida F2Pool, desempeñaron un papel central en la estabilización de la red al acordar reglas de validación actualizadas y rechazar datos MWEB malformados.
Esta coordinación ayudó a evitar que la explotación se propagara más a lo largo de la cadena.
El atacante posteriormente entabló negociaciones y devolvió la mayor parte de los fondos explotados.
Se recuperaron aproximadamente 84,184 LTC mediante transacciones coordinadas, mientras que una recompensa de 850 LTC se retuvo como parte del acuerdo a cambio de la cooperación para resolver el incidente.
En lugar de revertir la cadena, los desarrolladores optaron por un enfoque de reconciliación.
El sistema neutralizó efectivamente la salida inflada reequilibrando la contabilidad de MWEB mediante mecanismos controlados de peg-in y congelando las salidas inválidas.
Este enfoque permitió a la red restaurar la consistencia sin requerir un retroceso completo.
Segundo incidente provocó una reorganización de 13 bloques
Un segundo incidente relacionado ocurrió en abril de 2026, cuando intentos de reexplotar la misma vulnerabilidad expusieron una debilidad distinta en la forma en que los nodos manejaban datos MWEB malformados.
En esta ocasión, el problema no resultó en inflación adicional, sino que provocó inestabilidad en el procesamiento de los nodos.
Los nodos actualizados experimentaron bloqueos de procesamiento al encontrarse con bloques MWEB mutados, mientras que algunos mineros continuaron extendiendo una cadena construida con reglas de validación obsoletas.
Esta divergencia condujo a una reorganización temporal de la cadena de 13 bloques, con F2Pool minando una porción significativa de los bloques afectados durante el periodo de inestabilidad.
La reorganización fue de corta duración.
Una vez que los nodos actualizados obtuvieron la mayor parte del hashrate y rechazaron el historial inválido, la red convergió de nuevo hacia la cadena correcta. No quedó corrupción permanente del libro mayor tras la reconciliación.
Correcciones de protocolo y resolución final
Los desarrolladores publicaron actualizaciones de emergencia dentro de la serie Core 0.21.5.x, abordando tanto la falla de validación original como el problema secundario de manejo de bloques.
Las correcciones reforzaron la validación de entradas MWEB durante la conexión de bloques, mejoraron el manejo de estados de bloques mutados y reforzaron las comprobaciones de consistencia entre las capas de minería y consenso.
El análisis post-incidente confirmó que la explotación no resultó en inflación duradera ni en pérdida de integridad de la cadena final.
Sin embargo, puso de relieve la sensibilidad de los sistemas de bloques de extensión como MWEB, donde la mayor privacidad y complejidad introducen nuevos riesgos de validación.
Con la coordinación de mineros restaurada, los nodos parcheados desplegados y las salidas inválidas neutralizadas, la red ha vuelto a una operación estable.