Electrum 4.8.4 Blocks Lightning Onion Messages After Flaw

By Nathan Brooks

Electrum 4.8.4, released Nov. 6, now discards incoming Lightning Network onion messages after malformed messages from any source were found able to disconnect the Bitcoin wallet from a channel peer. The disclosure provides no loss amount or affected-user count.

According to Electrum’s release information, the wallet will “continue dropping those messages until Electrum implements a use for them.” The immediate measure blocks the disclosed route for channel disruption rather than restoring the affected message function. Electrum has announced no date for that later implementation.

The trigger condition carries a broader operational implication: Electrum attributes the failure to malformed messages from any source and does not name a specific operator or service. Wallet operators therefore cannot use sender identity as a shield against the disclosed path.

The reported consequence is loss of the channel-peer connection; the disclosure does not describe a monetary loss through the Lightning issue.

What does this change for Electrum users?

The release brings two changes. Users running version 4.8.4 no longer process the affected incoming onion messages, so malformed input cannot use the disclosed channel-disconnect path. The update also repairs wallet restoration for some seed phrases created before Electrum 2.0 that decode to an odd-length hexadecimal string.

Electrum’s response also narrows functionality. The stated behavior is not limited to one malformed format while preserving other incoming onion traffic: the wallet will keep dropping those messages until the project implements a use for them. In practical terms, 4.8.4 delivers containment for the connection risk and a separate recovery repair, not a completed implementation of onion-message handling.

The restoration defect had been present since version 4.6.1. Its stated scope is limited by two conditions: the seed phrase must have been created before 2.0, and its decoded hexadecimal form must have odd length. The disclosure does not say that every older seed phrase was affected or that users lost funds through the recovery failure.

For anyone maintaining Electrum installations, version identification matters. The Nov. 6 release followed the Oct. 24 binaries of 4.8.3 by 13 days, and each version addresses a different failure mode. Moving to 4.8.4 supplies both the message-discard behavior and the seed restoration repair; it does not replace the transaction-display fix already delivered in 4.8.3.

The 4.8.3 transaction-deception fix

Electrum’s previous version, 4.8.3, was dated Oct. 23, although its binaries were released Oct. 24. That release fixed a separate high-severity flaw involving a malicious server. Under the disclosed flaw, the server could hide a transaction the user had just broadcast and show the wallet a conflicting, invalid transaction containing the attacker’s address.

The dangerous sequence required the user to increase the fee on the displayed transaction through replace-by-fee, or RBF. If that occurred, the wallet could sign the false transaction and pay the attacker. The security significance lay in turning an ordinary fee adjustment into the signing step that delivered value to the substituted address.

The Nov. 6 update addresses a different exposure: malformed Lightning input and the availability of channel-peer connections. It does not alter the specific server-deception scenario already fixed in 4.8.3. Together, the releases show Electrum addressing three operational risks in sequence: misleading transaction presentation, failed restoration for a defined subset of old seed phrases, and malformed messages that can break a Lightning channel-peer connection.

The Lightning response remains deliberately incomplete while the project decides how to use incoming onion messages securely. Electrum has set no implementation deadline, so the next operational checkpoint is the release that reintroduces or defines that feature rather than a stated enforcement date.