A Rogue Electrum Server Replaced a Payment With a Zero-Fee Fake. The Fee Bump Signed the Attacker's Copy

What Happened

On Saturday, October 24, the Electrum project released version 4.8.3 and published a security advisory, GHSA-6jp4-8v48-cc5v, titled 'Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it.' Electrum, one of the oldest Bitcoin desktop wallets and a common front end for hardware wallets, is a light client: it does not download the blockchain, and instead asks a server for the history of its addresses.

The advisory describes a server that abuses that position. When the wallet broadcasts a payment (call it tx1), the server holds it instead of relaying it. It then serves the wallet a second transaction, tx2, that spends the same coins but sends them to the attacker's address. Tx2's signatures are invalid, 'but this is not checked (due to light client design).'

The wallet shows tx2 in its history as the user's own unconfirmed payment and hides tx1.

The forgery is built to be bumped. The server, the advisory says, 'constructed a tx2 with zero fee,' 'presumably in hope of the user bumping its fee.' A zero-fee transaction never confirms, so the user sees a stuck payment and reaches for the standard remedy, Replace-by-Fee (RBF): the wallet rebuilds the transaction with a higher fee and the user signs it.

Because the wallet rebuilt tx2, the new signature is valid and the coins go to the attacker. 2 users reported it privately. The first, on Sunday, October 11, found a transaction in their history they had not made and that their real payment had never propagated over the peer-to-peer network.

The second, credited as Raju-K12, reported on Sunday, October 18, that they had bumped the fee and lost money. In both cases the attacker's output address had been 'grinded to match the last four chars of the legit address from tx1.' The fix was tagged on Friday, October 23; the binaries and the disclosure followed the next day.

The advisory, published by the maintainer who goes by SomberNight, states that 'some servers are performing this attack in the wild' and gives no loss total, server count, or number of victims.

A fee bump is a second signature on a transaction you did not read the first time. Electrum now checks the signatures it never did; the history it checks still comes from whichever server picked up the call.

The Wallet Verified the Block. It Took the Server's Word for the Mempool

Electrum's documentation has long said where its trust ends. The client 'never sends private keys to the servers,' and for confirmed transactions it checks the server's answers against block headers using simplified payment verification, a Merkle-proof check against the block headers.

Unconfirmed transactions have no block to check against. The FAQ says the main server is trusted with the mempool, and the advisory repeats it: 'The main Electrum server the client connects to is trusted with mempool.' By default the wallet keeps connections to about 10 servers, 'arbitrarily' picks 1 as the main server, bootstraps from a hardcoded list, and asks each server for peers to find more; anyone can run one.

The main server is also the one that broadcasts your transactions. So the component that relays your payment, the component that tells you whether it went out, and the component whose version of events your fee bump is built from are the same machine, chosen at random from a list that strangers can join.

What 4.8.3 changes is narrow and precise. Before the wallet adds an unconfirmed transaction to its history, it now verifies the signatures on any input that spends the wallet's own coins; a transaction that fails is dropped, and if a server's history contains one, the client discards it and asks again.

The merge touches 7 files and adds 446 lines, most of them tests. What it does not do matters as much. Incoming transactions are still not validated: the advisory says the client 'lacks a full consensus engine / script interpreter,' and checking an input the wallet does not own would mean validating its unconfirmed parents 'recursively until reaching mined txs.'

A malicious server can still show you a payment that does not exist. It can no longer show you one you did not sign.

The Same Layer Was the Attack in 2018. The Same Release Closes Both Doors

This is not the first time Electrum's servers have been the weapon. From December 2018, operators of malicious servers used the way the client rendered server error messages to push fake 'update' prompts that led to trojaned downloads; Malwarebytes put the theft at about $4.6 million by April 2019 and described the operation as a Sybil attack in which hostile servers outnumbered honest ones.

The client stopped rendering those messages as rich text in early 2019. The 2026 attack needs no download and no prompt: it works entirely inside the data the wallet is designed to accept from a server. 4.8.3 reinforces the old door as well: its release notes 'disable rich-text string rendering by default.'

The same release notes carry a third line worth reading beside last week's: 'bump certifi and pip to distrust revoked eMudhra/emSign cert.' OPNorange's October 22 piece, 'A Certificate Authority's Private Key Was 4. Your Lightning Node's Trust List Is Compiled Into the Binary,' argued that software shipping its own trust store needs its own update and named Python's certifi bundle as one such store.

Electrum is Python; this is that update. The case for Electrum's design deserves its hearing. A light client that cannot run a full node cannot validate a mempool; the tradeoff has been documented for years; the fix shipped 6 days after the loss report and 13 days after the first; and the attack needs a victim who both lands on a hostile server and chooses to bump a fee.

2 reports is the public count. The advisory's 'in the wild' is the reason it is not a footnote.

What This Means for You

First, update, and update the way the 2018 campaign taught. Download 4.8.3 only from electrum.org, never from a prompt inside the wallet, and verify the release signature against Thomas Voegtlin's key, as the project's own instructions say to do 'every time you download a new version.'

If you bumped a fee on a stuck Electrum payment in October, open that transaction and read every output address in full against the one you meant to pay; a loss through this vector looks, in the history, like a payment you made. Coins sent this way are not recoverable; the report is still worth filing, since the maintainers have published no count.

Second, choose the server. The advisory says 'Clients that connect to servers they trust (e.g. run their own) are not affected.' Electrum's command line has the flags: '--server' sets a host and switches automatic selection off, and '--oneserver' means 'connect to one server only'; the desktop client's network settings offer the same choice under 'Connection mode.'

A server on your own node (electrs, Fulcrum, or Electrum Personal Server, as the February guide 'A Complete Bitcoin Security Setup for Under $300' laid out) sees nothing it should not and tells you nothing it cannot prove. The FAQ already recommends it on privacy grounds, since the main server learns your addresses and can tie them to 1 owner; this week adds the integrity argument.

If you cannot run one, pin 1 you have a reason to trust rather than take 1 of 10 at random.

Third, read the whole address, on every signature, fee bumps included. The attackers ground their addresses to match the last 4 characters of the real recipient's because that is what people check; Casa's Jameson Lopp reported in April 2025 about 48,000 suspected address-poisoning cases built on the same habit, matching the first 4 and last 4.

A hardware wallet helps here only as far as you use it: the device will show you tx2's outputs before it signs, and a glance at the tail will pass them. This is where self-custody's claim should be stated at its real size. Your private keys were never at risk in this attack; the key did exactly what a key does, which is sign what it was handed.

Key control decides who can sign. It says nothing about what the screen in front of you is showing, and a light wallet's screen is drawn from a server's answer. The signing ceremony is the last check in self-custody, and the only part of it a server cannot fake is the part you read yourself.

What to Watch

Whether the Electrum team publishes a count of malicious servers, or a blocklist, is the first thing to watch; the advisory names none. The second is the incoming side: 4.8.3 validates only the wallet's own spends, so the next abuse of a trusted server is a payment that was never made, shown to a seller who releases goods against an unconfirmed balance.

The third is the rest of the Electrum-protocol ecosystem. Sparrow, BlueWallet, and the hardware-wallet suites that accept a custom Electrum backend all take unconfirmed history from a server of the same kind; whether each verifies signatures on it is a question for their maintainers, not an assumption, and as of this writing none has published an answer.

And no loss figure has been given; if a large one surfaces, the 2-report advisory becomes the first public line of a campaign.