In normal mempool and block construction paths, that check existed. But it was not fully enforced during block connection. That gap allowed a malicious block producer to include an MWEB input whose supplied metadata did not match the real UTXO, making a small input appear capable of supporting a much larger pegout.
“The intended rule is simple: when an MWEB input spends a previous output, the metadata supplied by the input must match the actual MWEB UTXO identified by the input’s output ID,” the postmortem states. “That check existed in some paths, including normal mempool and block construction paths. But it was not fully enforced in the block connection path.”
Because exploitation required bypassing normal transaction relay and block-building checks, the attacker needed to mine a block or control a miner willing to include malformed MWEB data.
Miner Coordination, Frozen Outputs And RecoveryOnce developers identified the vulnerability and confirmed it had already been exploited, they coordinated privately with major mining pools. The aim was to prevent further exploit blocks without immediately alerting the actor before the inflated outputs could be contained.
Litecoin Core 0.21.5 and 0.21.5.1 were deployed as emergency miner-focused releases. The latter added a historical exception for the already-accepted exploit block and temporarily rejected spends of the three attacker-controlled transparent outputs.
The attacker later attempted to spend at least one frozen output, but upgraded miners rejected the transaction. Developers then contacted the actor, who agreed to sign a recovery transaction returning the funds except for an 850 LTC bounty.
Litecoin developers said no confirmed user funds were ultimately lost in the March incident. Still, the response required emergency miner coordination, staged releases and special-case handling of historical exploit data.
April Attempt Triggered A 13-Block Invalid ChainThe second incident began on April 25 at block height 3,095,931, when another actor attempted to use the same original exploit path. Upgraded nodes rejected the malformed MWEB data, but the rejection exposed a separate mutated-block handling issue.
The postmortem explains that some serialized MWEB body data could be mutated without changing the canonical Litecoin block hash. When an upgraded node received such a mutated MWEB block over peer-to-peer channels, it could fail while applying the MWEB body, classify the failure as “BLOCK_MUTATED,” and retain the bad serialized data for that block hash. That could interfere with later valid block processing and mining RPC flows such as submitblock.
“During the April incident, this caused upgraded mining nodes to reject the bad block but also become unable to continue normal mining operations quickly enough,” the postmortem states. “Unupgraded miners, which did not enforce the MWEB fix, continued extending the invalid chain until upgraded miners coordinated and overtook it.”
The invalid chain ran through block height 3,095,943, producing 13 bad blocks in total before the valid chain overtook it. Litecoin developers emphasized that this was not a rollback of valid Litecoin history, but a reorg of an invalid chain produced by miners that had not upgraded or had not fully enforced the MWEB validation rules.
Third-Party Losses Remain A Key Open IssueOther attempted swaps were reportedly prevented in time, but exact third-party transaction IDs and final loss amounts were still being collected.
Litecoin Core 0.21.5.4 was released on April 25 to address the mutated-block DoS failure mode by erasing stored block data for blocks classified as mutated, allowing valid data for the same block hash to be accepted later. Users, miners, exchanges and services were urged to upgrade to Litecoin Core 0.21.5.4 or later and verify that nodes are syncing normally.
At press time, LTC traded at $55.95.
