Electrum Bug Let Rogue Servers Steal Bitcoin via Fee Bumps

Electrum, one of Bitcoin's longest-running desktop wallets, has patched a flaw that let a malicious server trick users into paying an attacker. The trap sprang when a user tried to speed up a stuck payment by raising its fee.

The team rated the bug High in a security advisory published on Oct. 24. Every version below 4.8.3 is affected, and the advisory says some servers are already running the attack in the wild. At least one user lost money.

Why an Electrum Server Can See Your Payments First

Electrum is a light client. It doesn't download and check the whole blockchain itself. Instead, it connects to an Electrum server, which passes along information about your wallet and broadcasts your transactions to the network.

For transactions that haven't been confirmed in a block yet, the ones still waiting in the mempool, the wallet trusts that main server. The advisory is clear that this is documented design, not an accident. It is also the opening the attackers used.

How the Swap Worked, Step by Step

Picture sending a payment and watching it appear in your history as normal. Under the hood, a dishonest server could be doing something quite different:

1. You broadcast a new transaction, call it tx1. The server quietly swallows it instead of passing it on.
2. The server then puts a conflicting transaction, tx2, into your wallet's history. It spends the same coins but swaps the outputs for the attacker's address.
3. Tx2 carries invalid signatures. Because of the light client design, the wallet doesn't check them, so it looks like your payment.
4. If you then use RBF (replace-by-fee, which lets you rebroadcast a pending transaction with a higher fee) to bump tx2, your wallet signs it properly with the higher fee. Now it's a valid transaction, and it pays the attacker.

The nasty part is that the user does the final signing. Without the fee bump, tx2 is just a forgery the network would reject.

What the Two Victims Reported

Electrum received two user reports. The first user noticed their wallet history showed a different transaction from the one they had just broadcast. They also reported that tx1 never propagated over Bitcoin's peer-to-peer network, meaning the server simply held onto it.

The second user bumped the fee on tx2 and lost money. In that case, the server had built tx2 with a zero fee, which the developers say was presumably meant to tempt the user into bumping it. A transaction with no fee tends to sit unconfirmed, and bumping is the natural response.

Both users said the attacker's address had been ground to match the last four characters of the real recipient's address. That's a small, deliberate detail. Plenty of people glance at the end of an address to confirm it's right, and these attackers built for exactly that habit.

The advisory doesn't say how much was taken in total, which servers were involved, or whether anyone beyond these two users was hit.

What Version 4.8.3 Changes

The fix, in commit 90fe308, adds one check. Before adding an unconfirmed transaction to its local history, the wallet now verifies the signatures on any inputs that spend from its own addresses. A forged tx2 with bad signatures no longer makes it into your history, so there's nothing to bump.

The developers flag a limit. Only those own-wallet inputs are validated, so incoming unconfirmed transactions are still not checked.

For anyone who hasn't upgraded, the advisory's workaround is simple: when signing any transaction, fee bump or not, check that the output addresses and amounts are what you expect. People who connect only to servers they trust, such as one they run themselves, are not affected.

Two Weeks From First Report to Patch

The advisory lays out the timeline:

• Oct. 11: The first user disclosed the problem privately. The fee-bump route to theft wasn't yet understood.
• Oct. 18: A second user, Raju-K12, reported privately that they lost money after bumping a fee.
• Oct. 23: Version 4.8.3 was tagged.
• Oct. 24: The 4.8.3 binaries were released and the bug was disclosed publicly.

The gap between the first and second reports is the telling part. A swapped transaction in your history looked odd but harmless at first. It took a real loss to show what the attackers were actually waiting for: a user trying to be helpful to their own stuck payment.