Electrum 4.8.3 Patches Bitcoin (BTC) Wallet Flaw That Redirected Payments to Attackers

Rogue Servers Swapped Pending Payments

Rogue servers connected to the Electrum Bitcoin (BTC) wallet swept user funds by replacing a pending payment with a forged one, and the fee-bump a user then triggered to unstuck it signed money straight to an attacker-controlled address. The wallet's developers shipped the fix, version 4.8.3, on October 24, closing a high-severity vulnerability that affects every release before it. Nothing in the incident moved the Bitcoin (BTC) price or touched the network itself; the exploited system was Electrum's trust model for unconfirmed transactions, under which the wallet leans on the server it connects to rather than verifying payments on its own. When a user broadcasts a payment through a compromised server, that server can suppress the real transaction and inject a conflicting one that shows an attacker's wallet address and a zero fee. The forged entry sits in the history as a legitimate-looking pending payment that appears stuck, and because Electrum does not verify signatures on unconfirmed transactions a server hands it, nothing in the display flags the fake. The moment the user fee-bumps the stalled payment, a Replace-by-Fee action in practice, they sign and broadcast a completely valid new transaction, the first one actually to reach the network, and its output pays the attacker; the original payment was never sent.

The security advisory the Electrum team published on GitHub states that servers running this attack have been observed in the wild, backed by two user reports. A user posting as dannydeezy flagged suspicious server behavior on October 11; the doctored transaction never propagated past the local server, so no funds were lost. A second user, Raju-K12, confirmed a real loss on October 18 after fee-bumping a transaction a server had manipulated. The advisory also details a second layer of deception: attackers can grind the fake output address so its last four characters match the tail of the user's intended destination, defeating anyone who spot-checks only the end of a long address string before signing.

4.8.3 Closes the Main Attack Surface

Version 4.8.3, described in the official advisory and tagged in the Electrum repository on October 23, closes the main attack surface by verifying cryptographic signatures on wallet-owned inputs before any unconfirmed transaction enters local history. A server can no longer inject a fake transaction that touches the user's own addresses without providing valid signatures, which an attacker cannot forge; the release 4.8.3 binaries were published on October 24. The advisory acknowledges one remaining gap: incoming transactions from external senders, where none of the inputs belong to the user's wallet, are still accepted without signature verification, and closing that path would require additional work the team has not scheduled. The open server model is what makes this class of attack possible at all: anyone can run an Electrum node, and the wallet has no built-in way to know which server is honest. That delegation is a deliberate design tradeoff, since it keeps the lightweight client fast and small, and 4.8.3 now shifts part of that verification back to the wallet itself for the user's own inputs. This is not the first campaign of its kind against the long-running Bitcoin wallet project. A 2018 wave used rogue servers to push fake update notifications, and by 2020 it had drained an estimated $25 million from Electrum users. Users who connect exclusively to a server they run themselves are not affected by the current exploit. Anyone who cannot update immediately should manually verify output addresses and amounts before signing any transaction; the team has not disclosed any losses beyond the one confirmed on October 18, and its two user reports are the only documented cases so far. Version 4.8.3 is available at electrum.org alongside the project's GitHub repository.

The mechanism deserves a close look because it weaponizes the very step an attentive user takes: fee-bumping a stalled payment is the responsible reaction to a stuck transaction, and the zero-fee forgery was built to look like one. The exploit is not a replay attack in the strict sense; the transaction the victim signs is new and valid, it simply pays the wrong party. Our reading of the advisory is that users should move to 4.8.3 immediately, check a full wallet address rather than its final characters, and keep long-term holdings in a cold wallet or a hardware wallet, which takes the server out of the signing path entirely. As of 4.8.3 the main attack surface is closed; the unverified path for externally sent transactions remains open, and the team has given no date for closing it.