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

热门币种推荐

你可能也喜欢

是否还有希望?: 专家给出《清晰法案》通过并催生有利于加密货币立法的百分比概率

分析公司Galaxy Research将美国《清晰法案》(CLARITY Act)在2026年前获得通过的概率下调至10%。该法案旨在为加密货币市场建立监管框架,此前曾获两党支持并在参议院银行委员会推进,但政治分歧和行业游说延缓了进程。主要障碍包括未能就政府官员在加密领域的道德规范达成共识,以及地方银行施压导致部分共和党参议员支持减弱。法案中关于区块链监管和开发者保护的附加限制条款也使谈判复杂化。 由于参议院多数党领袖未能争取到足够的票数,法案未能在八月休会前表决,计划九月复会后提交。但九月会期因选举活动将于十月初结束,立法窗口极为有限。Galaxy指出,法案的关注重点已从政策内容转向政治平衡。 鉴于立法进程受阻,美国证券交易委员会(SEC)和商品期货交易委员会(CFTC)可能加快通过行政手段制定加密市场新规。SEC正准备推出两项酝酿已久的监管豁免:“加密监管豁免”旨在为加密资产首次公开发行建立新机制,“创新豁免”则寻求为代币化证券在去中心化金融协议中的二级市场交易建立框架。Galaxy认为,SEC近期重新推动这些规则,可能表明其认为《清晰法案》在国会通过的机会已显著降低。 尽管SEC和CFTC的监管行动能在短期内填补国会立法空白,为加密资产的发行、交易和市场监督提供更明确的指引,但此类行政措施无法提供与国会立法同等的长期法律确定性,未来新政府可能修改或废除这些规则。因此,它们不能替代国会通过的长期市场结构法案。Galaxy预计,即使《清晰法案》未获通过,SEC也可能在近期发布相关规则文本。

cryptonews.ru32分钟前

是否还有希望?: 专家给出《清晰法案》通过并催生有利于加密货币立法的百分比概率

cryptonews.ru32分钟前

交易

现货

热门文章

如何购买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)币价的意见。

活动图片