Electrum disables incoming onion messages after peer-disconnection flaw

Electrum has released version 4.8.4 of its Bitcoin wallet and temporarily disabled incoming Lightning onion messages after developers found that malformed messages from arbitrary origins could disconnect the software from a channel peer.

The project dates the security update to November 6. Electrum’s official download server listed packages and corresponding signature files for Android, Linux, macOS and Windows on November 8, making the fix available before Coinburn’s November 9 publication. The server directory displays a single November 8 timestamp for the files but does not identify its timezone.

The change matters because a Lightning wallet depends on peer connections to use payment channels. A forced disconnect is an availability problem: it can interrupt a wallet’s Lightning connectivity until a peer connection is restored. The published records do not establish theft, loss of keys, a Bitcoin consensus failure or a compromise of the Lightning Network as a whole.

Electrum chose to switch the feature off

Onion routing wraps data so that each hop learns only the information needed to forward it. Lightning’s specification applies that design to payments and also defines onion messages, which can carry non-payment data across a routed path.

Electrum’s release notes say malformed incoming onion messages could cause the wallet to disconnect from its channel peer. The associated code review shows developers merged three commits on November 6: one to handle invalid packets, one to clean up checks and limit blinded-path construction, and one to drop incoming onion messages.

The review gives the project’s reason for the broader switch-off. Developers said incoming onion messages were not useful to Electrum until it supported BOLT 12, while the existing peer-level processing delay did not provide sufficient rate limiting. Version 4.8.4 therefore drops incoming onion messages until Electrum has an implemented use case, rather than only attempting to reject the known malformed input.

That is a defensive reduction in functionality, not evidence that onion routing itself has been removed. Electrum can still use Lightning payment channels; the change concerns incoming onion-message handling in this wallet implementation. The sources do not quantify how many Electrum users operate Lightning channels, how frequently onion messages reached them or how long a malicious disconnect could persist.

The disclosure leaves important gaps

Electrum credits reports from Felipe Knorr Kuhn, “muntedcrocodile” and “haoxucu.” It does not publish a severity rating, CVE identifier, affected-version range, proof of exploitation or incident count for this issue. Those omissions prevent a reliable estimate of exposure.

The update also repairs unrelated wallet and interface problems. Release notes say it restores some pre-2.0 seeds that had decoded to odd-length hexadecimal strings incorrectly since version 4.6.1, addresses slow child-transaction calculations and fixes freezing in the desktop Coins tab for large wallets. Android changes include stale unspent-output and crash fixes. Those are bundled fixes; they should not be conflated with the onion-message security issue.

Electrum 4.8.4 follows version 4.8.3, dated October 23, which addressed a separate high-severity transaction-substitution problem involving a malicious Electrum server and replace-by-fee. The new release notes do not say that the earlier flaw returned. Treating the two updates as one continuing exploit would overstate the available evidence.

What to watch next

The immediate verified development is narrow: Electrum shipped 4.8.4 packages with signature files and disabled incoming onion messages after identifying a peer-disconnection path. The project has not stated when it will restore that functionality or what safeguards would accompany BOLT 12 support.

A fuller assessment will require a dedicated advisory or technical disclosure identifying affected versions, attack prerequisites, severity and any observed exploitation. Until then, the release demonstrates a concrete mitigation and available software update, but not the scale or real-world use of the flaw.