Electrum Showed Users a Payment They Never Made, Then Let Them 'Speed It Up.' Bumping the Fee Sent the Bitcoin to an Attacker
You send some bitcoin from Electrum. Your history shows a pending transaction for the right amount, sent to an address ending in the right four characters, with a fee of zero.
So you do what anyone would and hit “Bump fee” to get it confirmed.
The wallet then signs a fresh transaction that pays someone else. The pending entry was never your payment. A malicious Electrum server put it there, and when you bumped it you signed the payment to the attacker yourself.
Electrum’s developers say this is happening “in the wild.” On October 24 they shipped version 4.8.3 and published a security advisory rated High severity. Every version before 4.8.3 is affected.
What Happened
| Software | Electrum Bitcoin wallet, all versions before 4.8.3 |
| Attacker | A malicious Electrum server (the public servers your wallet connects to by default) |
| Trigger | User manually fee-bumps (RBF) the fake pending transaction |
| Reports | 2 user reports; 1 confirmed loss (amount not disclosed) |
| First report | October 11, 2026 |
| Loss reported | October 18, 2026 |
| Fix tagged | October 23, 2026 |
| Fix released + disclosed | October 24, 2026 |
| Not affected | Users connected only to servers they trust, such as their own |
How the Attack Works
Electrum is a light client. It doesn’t download the blockchain. It asks a server which transactions belong to your addresses, and before this fix it didn’t check signatures on the transactions the server sent back. The advisory describes it in five steps:
- You broadcast a real transaction (tx1) through the server.
- The malicious server “swallows” it and never relays it.
- The server adds a conflicting tx2 to your wallet history. It spends the same coins but “replaces the outputs with the attacker’s output address.”
- tx2 has invalid signatures, which Electrum didn’t check “due to light client design.” The wallet shows tx2 as unconfirmed, and tx1 disappears from view.
- If you RBF fee-bump tx2, “the client will sign it with a higher fee, and hence pay the attacker.”
In step 5 the wallet takes the attacker’s fake as a template and creates a new, validly signed version of it. The fake can’t be broadcast because its signatures are invalid. The bumped one can, and it carries your signature.
The details that make it work
The advisory includes two details that show how much thought went into this:
- The attacker’s address was “grinded to match the last four chars of the legit address.” Plenty of people only check the ends of an address. The attacker generated addresses until one matched those four characters.
- For the victim who lost money, the server “constructed a tx2 with zero fee (presumably in hope of the user bumping its fee).” A zero-fee transaction never confirms on its own, so the stuck payment itself pushed the victim toward the bump button.
In the first report, the fake copied the real transaction’s inputs, version and locktime. According to the advisory, “All 62 signatures verify against the real tx and none against the fake.” That user noticed the history didn’t match what they had sent and didn’t bump it. The second user bumped it and “lost money.”
What 4.8.3 Fixes, and What It Doesn’t
Electrum 4.8.3 now validates the signatures on transactions that spend from your own addresses, so a forged outgoing payment shouldn’t appear in your history any more.
The advisory notes a limit: “even with the fix, we still only validate ‘is_mine’ inputs… So e.g. ‘incoming’ txs are not validated.” Incoming transactions are still taken on trust from the server. Most news coverage left that part out.
Other wallet teams are already reacting. Per The Cryptonomist, Bull Bitcoin CEO Francis Pouliot said his team is “immediately adding a client-side validation using the same approach as Electrum wallet.” Any wallet that trusts server-supplied transaction history should check whether it’s exposed.
What To Do Right Now
- Update to 4.8.3, and download it only from electrum.org. Verify the GPG signature. Fake “security update” downloads tend to show up right after an advisory like this.
- Until you’ve updated, don’t fee-bump anything you can’t verify. Electrum’s own workaround is to “verify the output addresses and amounts are as expected.” Check the whole address, not only the last four characters.
- If a pending transaction doesn’t match what you sent, stop. Don’t bump it, cancel it or re-sign it. Check the txid on a block explorer you trust.
- Run your own server (Electrs, Fulcrum or ElectrumX against your own node) if you hold real money. The advisory says clients that connect only to trusted servers “are not affected.”
This Isn’t Electrum’s First Trust Problem
Electrum’s earlier 4.7.1 release notes described a different attack: malicious bitcoin addresses had been inserted into translated UI strings, and “One user sent funds to one such address and hence lost money.”
The two attacks use different routes but rely on the same weakness. Electrum is a 2011-era wallet built on trusting outside infrastructure, whether that’s translation contributors or random public servers. Attackers are now finding where that trust is assumed and exploiting it.
Why This Matters for Crypto Jobs
Wallet security is now a specialist job. This bug wasn’t in the cryptography. It came from what the light client trusted and from how the “Bump fee” flow interacted with that. Wallet teams need security engineers who think like a hostile server, not only like a hostile key thief, and there aren’t many of them.
Teams that ship RBF, CPFP and cancel buttons need someone who knows the Bitcoin transaction model in depth. Each of those features re-signs something. Engineers who understand transaction construction, replacement rules and SPV trust assumptions are scarce and well paid.
Small open-source teams now get attacks built for them. Electrum is maintained by a small core team, and the attacker ground out vanity addresses and planned a zero-fee lure around a single wallet’s quirks. Grants, foundations and companies that depend on open-source wallets will need to fund audits, bug bounties and paid maintainer time, or deal with the next advisory unprepared.
Infrastructure roles are coming back. “Run your own server” only helps if people can do it easily. Expect more hiring for node and indexer engineers and for the companies building plug-and-play Bitcoin infrastructure.
The Bottom Line
Nobody broke Bitcoin, and nobody stole a private key. A server lied about the wallet’s history, the wallet believed it, and the user trusted the wallet. A wallet should treat anything it didn’t sign or verify itself as possibly hostile, and before 4.8.3 Electrum didn’t. Update, and check the full address before every signature.
Want to build wallets that don’t trust the server’s version of your history? Browse open security and Bitcoin engineering roles on Cryptogrind →
Discussion
Comments are powered by GitHub. Sign in with your GitHub account to chime in.