Litecoin’s MWEB Bug Let An Attacker Create 85,034 LTC

bitcoinist发布于2026-04-29更新于2026-04-29

Litecoin developers have disclosed that a critical validation flaw in the network’s Mimblewimble Extension Block implementation allowed an attacker to create an inflated pegout of 85,034.47285734 LTC in March 2026, before a coordinated emergency response recovered the funds and neutralized the accounting imbalance.

The incident, detailed in a postmortem published by Litecoin developer David Burkett on April 28, also set the stage for a second April event in which a later exploit attempt triggered a denial-of-service failure mode, disrupted upgraded mining nodes, and led to a 13-block invalid chain being reorged out.

A Critical Litecoin MWEB Validation Failure

According to the postmortem, the root issue was a missing validation check in Litecoin’s MWEB block connection path. MWEB inputs are supposed to reference previous MWEB outputs, while carrying metadata used by balance and spend validation logic. That metadata must match the actual MWEB UTXO being spent.

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.”

The exploit occurred at block height 3,073,882. The attacker used an MWEB input with an actual value described as unknown, but “not more than 1.2084693 LTC,” while using fake commitment data to generate a pegout of 85,034.47285734 LTC. The inflated funds were initially sent to a transparent Litecoin address and later split into three transparent-chain outpoints.

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 Recovery

Once 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.

“The actor later signed a recovery transaction,” the postmortem says. “That transaction paid: 84,184.47278630 LTC total to the recovery address, split across two outputs. 850.00000000 LTC to an address controlled by the actor as the agreed bounty.”

The postmortem adds that Charlie purchased 850 LTC to cover the bounty gap. The full 85,034.47285734 LTC was then pegged back into MWEB at block height 3,078,098, and the resulting MWEB output was frozen. This was designed to restore MWEB’s internal supply balance while ensuring the rebalancing output could not be spent.

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 Chain

The 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 Issue

While the March exploit was recovered internally, the April reorg affected some external infrastructure. The postmortem says NEAR Intents processed a swap of 11,000 LTC for 7.78814476 BTC before those LTC were removed from the valid chain, resulting in what Litecoin described as a “large loss” for NEAR Intents. THORChain was also affected, with an attacker swapping 10 LTC for 0.00719957 BTC before the reorg invalidated the Litecoin side of the transaction.

Other 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.

Litecoin remains in bearish territory, 1-week chart | Source: LTCUSDT on TradingView.com

热门币种推荐

你可能也喜欢

Grayscale预测以太坊和Solana的稀缺性将增强

资产管理公司Grayscale的研究主管Zach Pandl在分析中指出,以太坊($ETH)和Solana($SOL)网络正在考虑调整代币经济学,这可能减少其原生代币的年供应增长率,从而增加资产的稀缺性。 报告预测,若拟议的协议变更得以实施,到2031年,比特币和以太坊的年化供应通胀率可能降至约0.4%,而Solana可能降至约1.1%。作为对比,黄金的年供应增长率约为1.8%,美国消费者物价通胀率约为3.3%。目前这些变更尚未获批,但Solana的提案被认为获得更广泛支持,通过可能性更高。 供应通胀降低将直接影响质押者的收益,因为其奖励来自新代币发行。奖励可能减少,但资产稀缺性可能支撑其市场价格。因此,非质押的代币持有者可能从供应减少中获益,而质押者的净收益将取决于奖励减少与资产潜在升值之间的平衡。 以太坊社区已就增加稀缺性展开具体讨论,例如提出了可能根据质押比例燃烧部分质押奖励的提案EIP-8363。Pandl总结认为,这些变化将增强两种资产的稀缺性,并可能对价格产生上行压力。 与此同时,Solana生态系统持续发展基础设施,例如正在测试旨在显著缩短交易最终确认时间的Alpenglow更新,并且其链上代币化资产规模在2026年第二季度已从第一季度的26.9亿美元增长至57亿美元。

cryptonews.ru3小时前

Grayscale预测以太坊和Solana的稀缺性将增强

cryptonews.ru3小时前

交易

现货

热门文章

如何购买S

欢迎来到HTX.com!我们已经让购买Sonic(S)变得简单而便捷。跟随我们的逐步指南,放心开始您的加密货币之旅。第一步:创建您的HTX账户使用您的电子邮件、手机号码注册一个免费账户在HTX上。体验无忧的注册过程并解锁所有平台功能。立即注册第二步:前往买币页面,选择您的支付方式信用卡/借记卡购买:使用您的Visa或Mastercard即时购买Sonic(S)。余额购买:使用您HTX账户余额中的资金进行无缝交易。第三方购买:探索诸如Google Pay或Apple Pay等流行支付方法以增加便利性。C2C购买:在HTX平台上直接与其他用户交易。HTX场外交易台(OTC)购买:为大量交易者提供个性化服务和竞争性汇率。第三步:存储您的Sonic(S)购买完您的Sonic(S)后,将其存储在您的HTX账户钱包中。您也可以通过区块链转账将其发送到其他地方或者用于交易其他加密货币。第四步:交易Sonic(S)在HTX的现货市场轻松交易Sonic(S)。访问您的账户,选择您的交易对,执行您的交易,并实时监控。HTX为初学者和经验丰富的交易者提供了友好的用户体验。

3.6k人学过发布于 2025.01.15更新于 2026.08.06

如何购买S

相关讨论

欢迎来到HTX社区。在这里,您可以了解最新的平台发展动态并获得专业的市场意见。以下是用户对S(S)币价的意见。

活动图片