Your Keys, Their Servers: Electrum’s RBF Flaw Turns Bitcoin Fee Bumps Into Silent Heists

(SeaPRwire) –

Open-source wallets sell you a dream. Electrum has been the face of that dream for over a decade. A self-custody wallet where you control the keys. Where no company holds your Bitcoin in escrow. Where the open-source community reviews every line of code. This week, that dream got a serious body check. Two users reported thefts in October. One on October 11. Another on October 18. The culprit was not a compromised seed phrase. It was not a phishing scam or a malware infection on the user’s device. It was the wallet’s own architecture. Rogue servers intercepted valid Bitcoin payments before they hit the network. They rewrote the destination addresses and left users none the wiser. The Electrum development team confirmed one actual theft and classified the vulnerability as high severity. Developers said some servers were already actively exploiting this method against users in the wild. The fix was tagged internally on a Friday, October 23, and released the following day. This is not a theoretical risk that a whitepaper mentions in passing. This is a live, confirmed, exploited flaw in a wallet that millions trust with their financial sovereignty.

The technical mechanism is deceptively simple. Electrum uses external servers for transaction records and broadcasting. When a user initiates a Bitcoin payment, the transaction routes through these servers before it reaches the Bitcoin network. This design choice allows the wallet to function without maintaining a full node. It means users get a lightweight client without running the entire blockchain themselves. The trade-off is that trust moves to the server. An attacker-controlled server could hold back a valid transaction that the user intended to send. Then the attacker injects a different pending transaction into the wallet’s history. This fake record lists the attacker’s address as the recipient. Here is the critical failure. Older versions of Electrum did not verify signatures on unconfirmed transactions that spent funds controlled by the wallet. The wallet accepted the forged transaction as legitimate without checking its cryptographic validity. The user’s wallet history showed a pending payment that did not actually exist as the user had authorized it. There was no warning. There was no discrepancy flag. The wallet simply displayed the forged transaction as if it were the user’s own intent. The first report came from a user operating a two-of-three multisig wallet secured with two Trezor hardware devices. This user had already taken significant precautions. They checked the original payment on both hardware devices before signing. Everything looked correct at that point. But after signing, they discovered another transaction sitting in their Electrum history. The attacker address in that substituted transaction ended in the same four characters as the originally intended destination address. This pattern appears in both reported cases. It suggests deliberate, targeted substitution designed to fool users who glanced at the tail end of an address. The first user’s report mentioned no actual loss of funds, only the presence of the anomalous transaction.

The second report on October 18 confirmed that real money changed hands. This user had selected the Replace-by-Fee feature on what they believed was their own pending payment. RBF, or Replace-by-Fee, is a standard Bitcoin protocol feature. It allows users to resend a pending transaction with a higher fee to speed up its confirmation time. The workflow is straightforward. You have a transaction stuck in the mempool. You bump the fee. You sign the new transaction with the same inputs. The higher-fee version replaces the original. The catch in this case was that the “original” transaction was already a forgery. Electrum signed the altered payment without flagging it because the signature verification gap meant the wallet never cross-checked the transaction against what the user actually authorized. The attacker had rewritten a payment’s destination address before the user’s private key was applied. The substituted payment carried zero transaction fee, which could make it appear stuck and incentivize the user to bump it. Once the user selected RBF, Electrum signed the payment to the attacker address. Bitcoin moved to a wallet the user never intended to fund. The RBF feature itself is not broken. It is a valid protocol mechanism designed for a legitimate use case. The flaw was in the wallet layer that mediated between the user and the protocol. Version 4.8.3 was released on October 24. The patch now checks signatures on unconfirmed transactions that spend funds controlled by the wallet. This closes the specific hole that allowed the forgery to pass through. But it does not eliminate the broader dependency on unaudited third-party servers for transaction visibility.

This vulnerability does not exist in isolation. It sits in a wider pattern of trust erosion across the self-custody wallet landscape. Foundation recently traced Passport phishing emails containing purchase details to compromised service keys. Those attacks did not use the transaction replacement method that Electrum described. They represent a different attack vector entirely. The Railway breach linked to crypto theft involved suspected exposed credentials rather than falsified pending payments. The Keystone wallet customer data breach exposed user data through a completely different failure mode. Each vector is technically distinct. But the pattern underneath is consistent. Self-custody wallets still rely on external infrastructure that users cannot verify, audit, or control. The wallet is “your own” in the sense that you hold the private keys. But the transaction layer that feeds you visibility into what those keys are spending operates on trust. Users choose a server at wallet setup. They have no ongoing ability to verify that server’s integrity. They have no way to know whether the server is manipulating the transaction state being displayed. Enterprise pricing for wallet services does not factor in the residual risk that users carry when their transactions traverse servers they chose once at install time. Electrum’s fix patches this specific verification gap. The underlying architectural dependency on third-party servers for transaction state remains untouched. Wallet providers market security features. None of them market the supply chain of trust that silently underpins every operation. The open-source community reviews code with scrutiny. No one reviews the servers that feed data into that code. That is the blind spot.

User sovereignty means nothing if your wallet history can be rewritten by a server you selected during setup. The Electrum incident is a sharp reminder that open-source code is only as secure as the infrastructure it assumes. Every Bitcoin holder running Electrum versions prior to 4.8.3 should verify their transaction history and update immediately. The fix is available. The version is tagged. The window of exposure has closed for new installations, but old versions remain vulnerable if left untouched. The harder truth that most users and providers will not confront is this. Signing a transaction you cannot fully audit independently is not sovereignty. It is trust wearing a disguise.