Exploit MWEB de Litecoin résolu, réorganisation des blocs corrigée

Litecoin a récemment affronté l'un de ses incidents techniques les plus graves liés à la fonctionnalité Mimblewimble Extension Blocks (MWEB), après qu'une faille de validation a permis à un attaquant de générer un peg-out gonflé d'environ 85,034 LTC.

Le problème a été tracé jusqu'à une défaillance dans la vérification au niveau de la connexion des blocs, où les métadonnées d'entrée MWEB ne correspondaient pas correctement à l'UTXO sous-jacent dépensé.

Bien que l'incident ait brièvement ébranlé la confiance dans la couche d'extension, il a finalement été contenu grâce à une réponse coordonnée des mineurs et des correctifs rapides du protocole.

Comment l'exploit MWEB s'est déroulé

Selon l'analyse post-mortem publiée par Litecoin, l'exploit a commencé en mars 2026 au height de bloc 3,073,882, lorsqu'un attaquant a exploité avec succès la faille de validation.

En manipulant les données d'entrée MWEB, l'attaquant a fait apparaître une petite entrée comme justifiant une sortie beaucoup plus importante lors du traitement du peg-out.

En réalité, la valeur de l'entrée sous-jacente n'était qu'environ 1–2 LTC, mais le système l'a incorrectement acceptée comme soutien valide pour plus de 85,000 LTC.

Il ne s'agissait pas d'un problème standard au niveau du portefeuille ou de la couche transactionnelle. Au contraire, il était lié à la façon dont les blocs MWEB étaient validés lors de la connexion à la chaîne.

Alors que le mempool et les couches de construction de transactions fonctionnaient correctement, l'étape finale de vérification au niveau du consensus a échoué à valider pleinement l'intégrité des métadonnées MWEB par rapport aux sorties référencées.

Une fois le peg-out anormal détecté, les mineurs ont rapidement identifié l'incohérence et lancé une action coordonnée pour empêcher toute propagation supplémentaire.

Les sorties suspectes ont été isolées, et une partie des fonds a été gelée au niveau du protocole afin d'empêcher tout mouvement supplémentaire sur le réseau.

Confinement, récupération et coordination des mineurs

Après la détection, les développeurs et les principaux pools miniers sont passés en mode de réponse d'urgence.

Les pools miniers, dont F2Pool, ont joué un rôle central dans la stabilisation du réseau en s'accordant sur des règles de validation mises à jour et en rejetant les données MWEB malformées.

Cette coordination a aidé à empêcher l'exploitation de se propager davantage sur la chaîne.

L'attaquant a ensuite entamé des négociations et rendu la majorité des fonds exploités.

Environ 84,184 LTC ont été récupérés par des transactions coordonnées, tandis qu'une prime de 850 LTC a été conservée dans le cadre de l'accord en échange de la coopération pour résoudre l'incident.

Plutôt que d'annuler la chaîne, les développeurs ont opté pour une approche de réconciliation.

Le système a effectivement neutralisé la sortie gonflée en rééquilibrant la comptabilité MWEB via des mécanismes de peg-in contrôlés et en gelant les sorties invalides.

Cette approche a permis au réseau de rétablir la cohérence sans nécessiter de retour en arrière complet.

Un second incident a déclenché une réorganisation de 13 blocs

Un deuxième incident lié est survenu en avril 2026, lorsque des tentatives de ré-exploitation de la même vulnérabilité ont révélé une faiblesse différente dans la manière dont les nœuds traitaient les données MWEB malformées.

Cette fois, le problème n'a pas entraîné d'inflation supplémentaire mais a provoqué une instabilité dans le traitement par les nœuds.

Les nœuds mis à niveau ont subi des blocages de traitement lorsqu'ils rencontraient des blocs MWEB mutés, tandis que certains mineurs ont continué d'étendre une chaîne construite sur des règles de validation obsolètes.

Cette divergence a conduit à une réorganisation temporaire de la chaîne de 13 blocs, F2Pool minant une part importante des blocs affectés pendant la période d'instabilité.

La réorganisation a été de courte durée.

Une fois que les nœuds mis à niveau ont obtenu la majorité de la puissance de hachage et rejeté l'historique invalide, le réseau est revenu à la chaîne correcte. Aucune corruption permanente du grand livre n'est restée après la réconciliation.

Correctifs du protocole et résolution finale

Les développeurs ont publié des mises à jour d'urgence dans la série Core 0.21.5.x, corrigeant à la fois la faille de validation initiale et le problème secondaire de gestion des blocs.

Les correctifs ont renforcé la validation des entrées MWEB lors de la connexion des blocs, amélioré la gestion des états de blocs mutés et consolidé les contrôles de cohérence entre les couches de minage et de consensus.

L'analyse post-incident a confirmé que l'exploit n'a pas entraîné d'inflation durable ni de perte de l'intégrité de la chaîne finale.

Cependant, cela a mis en évidence la sensibilité des systèmes à blocs d'extension comme MWEB, où la confidentialité accrue et la complexité introduisent de nouveaux risques de validation.

Avec la coordination des mineurs rétablie, les nœuds patchés déployés et les sorties invalides neutralisées, le réseau est revenu à un fonctionnement stable.