Litecoin’s 13 Block Reorganization Wasn’t Zero-Day, GitHub Commit History Shows Otherwise

A reorganization of the 13-block chain in On Friday night and Saturday they rewinded approximately 32 minutes of network activity after attackers exploited a vulnerability in their Mimblewimble Extension Block (MWEB) protocol.

The bug had enabled a denial-of-service attack against major mining pools, allowing invalid MWEB transactions to pass through nodes that had not been updated, before the longest valid chain on the network fixed them.

The Foundation said in the Asian morning hours of Sunday that the error had been completely fixed and the network was operating normally.

However, prominent researchers say that the litecoin project’s GitHub repository tells a different story. Security researcher bbsz, who works with the SEAL911 emergency response group for crypto exploits, published the patch timeline pulled from the public commit log.

The consensus vulnerability that allowed the invalid MWEB connection was patched privately between March 19 and March 26, approximately four weeks before the attack. Another denial of service vulnerability was fixed on the morning of April 25.

Both fixes were included in version 0.21.5.4 that same afternoon, after the attack had already begun.

“The autopsy says that a zero-day caused a DoS that allowed an invalid MWEB transaction to be leaked,” bbsz wrote. “The git log tells a slightly different story.”

A zero-day refers to a vulnerability unknown to defenders at the time of an attack.

Litecoin’s commit history shows that the consensus vulnerability was known and privately patched a month before the exploit, but the fix had not been publicly broadcast nor required to all mining pools.

That created a window where some miners ran the patched code while others ran the still vulnerable version, and the attackers appear to have known which was which.

Alex Shevchenko, CTO of the NEAR Foundation’s Aurora project, raised parallel concerns in a thread.

Blockchain data showed that the attacker pre-funded a wallet 38 hours before the exploit via a Binance withdrawal, with the destination address already set to exchange LTC for ETH on a decentralized exchange.

The denial of service attack and the MWEB bug were separate components, Shevchenko argued, and the DoS was designed to take patched mining nodes offline so that unpatched ones formed the chain that included the invalid transactions.

The fact that the network automatically handled the 13-block reorganization once the DoS was stopped suggests that enough hashrate was running on the updated code to eventually overpower the attack, but only after the unpatched fork had run for 32 minutes.

A success in Litecoin shows how attacks on various networks differ in how maintainers and code developers react to exploits. Newer chains with smaller, centralized sets of validators coordinate updates through chat groups and can deploy patches across the network in a matter of hours.

Older proof-of-work networks, like Litecoin and bitcoin, rely on independent mining pools that choose when to update, which works for non-urgent changes but creates a window of vulnerability when a security patch must reach everyone before an attacker exploits the gap.

The Litecoin Foundation has not publicly addressed GitHub’s timeline as of Sunday morning.

The amount of LTC locked in during the invalid lockup window and the value of swaps completed before the reorganization revoked them have not been disclosed.



Leave a Comment

Your email address will not be published. Required fields are marked *