Litecoin Entwickler haben einen schwerwiegenden Fehler in der Mimblewimble Extension Block (MWEB) Funktion offengelegt. Durch eine Lücke in der Prüfung von MWEB Daten konnte ein Angreifer im März 2026 einen viel zu hohen Pegout erzeugen und so rechnerisch 85.034,47285734 LTC „erschaffen“. Die Situation wurde durch ein Notfall Update und enge Abstimmung mit Minern entschärft, die Gelder konnten am Ende weitgehend zurückgeholt werden.
So entstand der MWEB Fehler und warum er so gefährlich war
Im Kern ging es um eine fehlende Validierungsprüfung beim sogenannten Block Connection Prozess, also beim Verbinden und endgültigen Akzeptieren eines Blocks durch Nodes. MWEB Inputs müssen dabei auf frühere MWEB Outputs verweisen und außerdem Metadaten mitbringen, die zur Prüfung von Betrag und Ausgabeberechtigung dienen. Diese Metadaten müssen exakt zu dem UTXO passen, der ausgegeben werden soll.
Laut dem offiziellen Postmortem von Entwickler David Burkett gab es diese Prüfung zwar in Teilen, etwa im Mempool und beim normalen Erstellen von Blöcken, aber sie war beim Block Connection Pfad nicht vollständig durchgesetzt. Genau diese Lücke ermöglichte den Angriff.
Der Exploit passierte bei Blockhöhe 3.073.882. Der Angreifer nutzte einen MWEB Input, dessen echter Wert laut Bericht unbekannt ist, aber bei höchstens 1,2084693 LTC lag. Mit manipulierten Commitment Daten ließ sich daraus trotzdem ein Pegout von 85.034,47285734 LTC konstruieren. Die neu erzeugten Coins landeten zunächst auf einer transparenten Litecoin Adresse und wurden später auf drei UTXOs aufgeteilt.
Wichtig dabei, der Angriff war nicht einfach über normale Transaktionsweiterleitung möglich. Damit der fehlerhafte Datensatz in die Chain kommt, musste der Angreifer selbst einen Block minen oder einen Miner finden, der den Block trotz der Unstimmigkeiten akzeptiert und produziert.
Notfallmaßnahmen, eingefrorene Outputs und Rückholung der LTC
Nachdem die Entwickler die Schwachstelle erkannt hatten und klar war, dass sie bereits ausgenutzt wurde, folgte eine koordinierte Reaktion mit großen Mining Pools. Ziel war es, weitere Exploit Blöcke zu verhindern, ohne den Angreifer sofort zu warnen, bevor man die betroffenen Outputs unter Kontrolle hatte.
Dafür erschienen kurzfristig die Versionen Litecoin Core 0.21.5 und 0.21.5.1 als minerfokussierte Notfall Releases. Version 0.21.5.1 enthielt zusätzlich zwei entscheidende Maßnahmen, erstens eine historische Ausnahme, damit der bereits akzeptierte Exploit Block nicht das Netzwerk sofort spaltet, und zweitens eine temporäre Sperre, sodass die drei transparenten Outputs des Angreifers nicht ausgegeben werden konnten.
Der Angreifer versuchte später mindestens einen dieser eingefrorenen Outputs zu bewegen, scheiterte aber an den aktualisierten Minern. Laut Postmortem wurde der Akteur anschließend kontaktiert und stimmte zu, eine Recovery Transaktion zu signieren. Dabei gingen 84.184,47278630 LTC an eine Recovery Adresse zurück, während 850 LTC als vereinbarte Bounty beim Angreifer blieben.
Zusätzlich erwähnt der Bericht, dass Charlie 850 LTC kaufte, um die Bounty Lücke abzudecken. Danach wurden die kompletten 85.034,47285734 LTC bei Blockhöhe 3.078.098 zurück in MWEB gepeggt, und der dabei entstehende MWEB Output wurde eingefroren. So sollte die interne MWEB Bilanz wieder stimmen, ohne dass dieser Ausgleich Output später ausgegeben werden kann. Litecoin betont, dass im März Vorfall keine bestätigten Nutzerverluste entstanden seien.
Zweiter Vorfall im April, 13 ungültige Blöcke und Verluste bei Drittanbietern
Am 25. April kam es zu einem weiteren Ereignis ab Blockhöhe 3.095.931. Ein anderer Akteur versuchte offenbar denselben ursprünglichen Exploit Weg. Gepatchte Nodes lehnten die fehlerhaften MWEB Daten zwar ab, doch genau diese Ablehnung löste einen separaten Fehler aus, der als DoS Problem beschrieben wird.
Der Hintergrund, bestimmte serialisierte MWEB Body Daten konnten so verändert werden, dass der eigentliche Litecoin Block Hash gleich blieb. Erhielt ein aktualisierter Node eine solche mutierte Variante, konnte er beim Anwenden des MWEB Bodys fehlschlagen, den Block als BLOCK_MUTATED markieren und die schlechte Version zu diesem Block Hash speichern. Das konnte später die Verarbeitung gültiger Daten behindern und sogar Mining Abläufe stören, etwa bei submitblock.
In der Folge konnten einige aktualisierte Mining Nodes nicht schnell genug normal weiterarbeiten, während nicht aktualisierte Miner eine ungültige Kette weiter verlängerten. Am Ende wurde die ungültige Kette nach 13 Blöcken wieder verworfen, sie lief bis Blockhöhe 3.095.943. Die Entwickler betonen, dass dies kein Rollback gültiger Historie war, sondern eine Reorg einer Kette, die von Minern ohne ausreichende Validierung gebaut wurde.
Offen bleibt jedoch der Schaden bei Drittanbietern. Laut Postmortem verarbeitete NEAR Intents einen Swap von 11.000 LTC gegen 7,78814476 BTC, bevor die entsprechenden LTC durch die Reorg aus der gültigen Chain verschwanden, Litecoin spricht hier von einem „großen Verlust“. Auch THORChain war betroffen, dort tauschte ein Angreifer 10 LTC gegen 0,00719957 BTC, bevor die Litecoin Seite des Trades ungültig wurde. Weitere Details wie finale Verlustsummen und Transaktions IDs wurden zum Zeitpunkt des Berichts noch gesammelt.
Als Reaktion wurde Litecoin Core 0.21.5.4 veröffentlicht. Das Update soll den mutierten Block DoS Effekt beheben, indem gespeicherte Blockdaten für als mutiert klassifizierte Blöcke gelöscht werden, sodass später gültige Daten mit demselben Block Hash wieder akzeptiert werden können. Miner, Börsen und Services wurden aufgefordert, auf 0.21.5.4 oder neuer zu aktualisieren und die Synchronisation ihrer Nodes zu prüfen.
