News analysis ·
Electrum fee-bump theft: how rogue servers did it
Electrum 4.8.3 fixes a flaw that let malicious servers turn Replace-by-Fee bumps into theft. How the attack worked and what the patch now checks.
Electrum, one of the oldest bitcoin software wallets, has shipped version 4.8.3 to close a flaw that let dishonest servers steal coins when users tried to speed up a payment. Both Unchained and CoinDesk reported on the advisory, which says the bug was already being used by attackers. This article explains where the trust gap sat, how a routine fee bump became the trap, and what the new check does and does not cover.
The change in one paragraph
According to Unchained, the Electrum team issued its advisory on Oct. 24, calling the bug high severity. Every release older than 4.8.3 is affected. Before the fix, the wallet accepted a server's word about pending payments without checking their signatures. A malicious server could show the user a fake pending transaction that paid the attacker. If the user then raised the fee, Electrum signed a real, valid replacement for that fake, and the coins went to the attacker. The patched release, out the same day, adds a signature check that blocks this path.
Under the hood: what a light wallet trusts
A full node downloads and checks every block and transaction itself. Electrum works differently. As CoinDesk explained, it depends on outside servers to fetch the wallet's history and to relay payments to the network. That keeps it light, but some information arrives on trust.
Unchained noted that trusting a server for the status of unconfirmed transactions is a documented part of Electrum's design. Unconfirmed transactions sit in the mempool, the waiting area of payments not yet in a block. The wallet cannot learn their status from the chain alone, so it asks the server, and a dishonest server has room to lie.
The second ingredient is Replace-by-Fee. Bitcoin lets a sender swap an unconfirmed transaction for a new version that pays a higher fee, so miners pick it up sooner. To do that, the wallet takes the pending transaction, raises the fee and signs the new version with the user's keys. The wallet assumes the pending transaction it starts from is the one the user actually made.
- The server holds back the genuine payment instead of passing it to the network.
- It feeds the wallet a substitute that spends the same coins to an attacker address. The substitute carries invalid signatures.
- Older Electrum did not check those signatures and showed the substitute as the payment in progress.
- In one reported case the fake had zero fee, so it looked stuck and invited a bump.
- When the user bumped the fee, Electrum built and signed a valid replacement from the fake one, paying the attacker.
The key point is that the attacker never needed the user's keys. The forged transaction itself could never confirm, because its signatures were invalid. It only had to look real long enough for the wallet to sign a genuine one on top of it. CoinDesk added that attackers generated receiving addresses whose final four characters matched the real destination, so a quick glance at the end of the address would not reveal the swap.
What the 4.8.3 check verifies, and what it leaves open
According to Unchained, the fix is a single check. When a pending transaction claims to spend coins belonging to the wallet, Electrum now verifies its signatures before adding it to the local history. A forged outgoing payment with bad signatures is therefore rejected before it can be displayed or used as the base for a fee bump.
The check is narrow by design, and the advisory says so. It names incoming transactions as an example of what Electrum still does not validate. In other words, the wallet still relies on its server for parts of the picture. The patch closes the theft route that was reported; it does not turn Electrum into a full node.
Who is affected
Users on any version before 4.8.3 who connect to public servers are the group at risk. The advisory, as quoted by Unchained, draws the line clearly: "Clients that connect to servers they trust (e.g. run their own) are not affected". CoinDesk likewise reported that users connected only to trusted servers, including their own, were not exposed.
The problem also surfaced in a careful setup. CoinDesk reported that the first report, on Oct. 11, came from a two-of-three multisig user with two Trezor devices, who saw an unexpected outgoing transaction in the history but reported no loss. The developers' advice to read the address and amount on screen before every signature applies here too.
Timeline and next steps
The private disclosure on Oct. 11 did not yet reveal the fee-bump route to theft, according to the advisory cited by Unchained. On Oct. 18 a second user, credited as Raju-K12, said they had raised the fee on the swapped-in payment and then lost funds. CoinDesk noted the patch shipped six days after that first reported theft. The size of the loss and the identity of the hostile servers remain undisclosed.
The developers advise upgrading to 4.8.3 and checking the destination address and amount on screen before every signature, with or without a fee bump.
Sources
AI wrote this summary from the primary documents and reports cited above. It went live automatically after checks that figures match those sources and nothing is copied; there was no human review. It explains a protocol or rule change and is not investment advice.