Electrum Patches a Fee-Bump Theft Attack Already Live on Servers

Electrum shipped version 4.8.3 on Saturday, fixing an attack its developers had already seen running on live servers. The flaw let a hostile server hide the payment a user had just broadcast and show a forged one in its place. Raising the fee on that forged payment handed the coins to the attacker. The project published a security advisory the same day. It is rated High and carries no CVE identifier.

How a fee bump becomes a payment

Electrum is a light wallet. It keeps no full copy of Bitcoin's ledger and asks a server what has happened to its addresses. The advisory is blunt: the server is trusted for unconfirmed transactions, and the client does not check their signatures. That is documented design, not an oversight. A malicious server swallows the transaction the wallet broadcasts and feeds back a conflicting one whose outputs pay the attacker. The forgery shows as pending and the real payment never appears. Nothing has moved yet, because the forgery is invalid and no miner will take it.

The theft needs the user. Replace-by-Fee, a Bitcoin feature that lets a sender resend a pending payment with a higher fee so it confirms sooner, is the lever. A user who bumps the fee by hand signs the replacement, and that signature is real.

"Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it," the advisory's title read.

Two reports, thirteen days

The first came in on 11 October from dannydeezy, who noticed a history entry that did not match what had been sent. The fee-bump route was not recognized then. On 18 October a second user, Raju-K12, reported losing money after raising a fee. Version 4.8.3 was tagged in git on 23 October and the binaries went out on 24 October, six days after the loss was reported. CoinDesk, filing early on Monday, puts the release on 24 October without separating the two dates, and says the first reporter did not report losing funds. The advisory says only that the fee-bump vector was not realized in that report. Those are not the same statement, and we could not establish which supersedes which.

crypto.news carries the longest description of that first case and stands alone on the detail: a two-of-three multisig wallet running two Trezor devices, and 62 signatures that checked out against the original transaction and failed against the substitute. No other account read here supplies that count.

The last four characters

Both cases share one touch. The attacker's receiving address was generated so that its final four characters matched those of the address the user meant to pay. Wallet software shows addresses truncated, and a reader checking the tail sees what they expect. In one of the two cases the forged transaction carried no fee, which is what made it look stuck. crypto.news reports that developers took the zero fee as bait for a fee increase. The advisory states no motive and this desk does not supply one. Coins have gone out of wallets this year on faked app alerts that pushed the holder into acting. Here the prompt came from the wallet's own server.

What 4.8.3 leaves open

The patch, commit 90fe308, makes the client verify signatures on the wallet's own inputs before an unconfirmed transaction enters local history. Only those inputs are checked. Incoming transactions are still taken on the server's word, so the fix is partial by design. Anyone who cannot upgrade is told to read output addresses and amounts before signing anything, fee bumps included. Clients that talk only to a server the owner runs were never exposed.

What nobody has published is a number. There is no loss total, no count of how many servers ran the attack, and no sign of whether anyone beyond the two reporters was hit. The operators have not been identified. Severity is unsettled too: the advisory says High, while crypto.news quotes a developer post calling it a critical security issue. Disclosure practice has been moving all year, and Bitcoin Core has dropped its embargo for bugs a language model can rediscover. Electrum held this one for thirteen days and shipped it while servers were exploiting it.