BREAKING
Oct 25Electrum Showed Users a Payment They Never Made, Then Let Them 'Speed It Up.' Bumping the Fee Sent the Bitcoin to an Attacker●Oct 24AUSD's Issuer Says Its Stablecoin 'Does Not Exist on Initia.' A Hacker Minted 2 Million There Anyway and Left With 1.4M Real Ones. The Chain Is Still Off●Oct 23CoinDCX Said Those Wallets Died in Its 2025 Hack. Then $16M Walked Out of Them, and the 'Rumour' Became 'Operational Losses'●Oct 22The OCC Just Wrote the Rule on Your 4% Stablecoin Yield. It Won't Say If Coinbase's 3.75% on USDC Is Legal●Oct 21Drift's Hacker Ran $61M Through Tornado Cash in Two Hours. Seven Months In, Only $9.2M of the $295M Has Been Frozen●Oct 19Nobody Hacked Qubic's Chain. Its Seeds Were Just Guessable. 1,404 Wallets Emptied in 104 Minutes, and the Whole Network Is Still Off●Oct 18Bitget Just Gave Traders in Russia, Belarus and Kazakhstan 72 Hours to Get Their Money Out. It Won't Say Why●Oct 17An OpenAI Model Ran Out of Gas Money, Checked 362 Public Wallets, Spent a Stranger's ETH and Left It Out of Its Report●Oct 16They Drained Victims' Life Savings, Then Called Back Offering to Recover It. Brooklyn Just Pulled 241 of Their Sites●Oct 15The SEC Couldn't Touch Richard Heart. A Finnish Tax Case Just Got Him Picked Up by Turkish Intelligence●Oct 25Electrum Showed Users a Payment They Never Made, Then Let Them 'Speed It Up.' Bumping the Fee Sent the Bitcoin to an Attacker●Oct 24AUSD's Issuer Says Its Stablecoin 'Does Not Exist on Initia.' A Hacker Minted 2 Million There Anyway and Left With 1.4M Real Ones. The Chain Is Still Off●Oct 23CoinDCX Said Those Wallets Died in Its 2025 Hack. Then $16M Walked Out of Them, and the 'Rumour' Became 'Operational Losses'●Oct 22The OCC Just Wrote the Rule on Your 4% Stablecoin Yield. It Won't Say If Coinbase's 3.75% on USDC Is Legal●Oct 21Drift's Hacker Ran $61M Through Tornado Cash in Two Hours. Seven Months In, Only $9.2M of the $295M Has Been Frozen●Oct 19Nobody Hacked Qubic's Chain. Its Seeds Were Just Guessable. 1,404 Wallets Emptied in 104 Minutes, and the Whole Network Is Still Off●Oct 18Bitget Just Gave Traders in Russia, Belarus and Kazakhstan 72 Hours to Get Their Money Out. It Won't Say Why●Oct 17An OpenAI Model Ran Out of Gas Money, Checked 362 Public Wallets, Spent a Stranger's ETH and Left It Out of Its Report●Oct 16They Drained Victims' Life Savings, Then Called Back Offering to Recover It. Brooklyn Just Pulled 241 of Their Sites●Oct 15The SEC Couldn't Touch Richard Heart. A Finnish Tax Case Just Got Him Picked Up by Turkish Intelligence●
BTC -- --%
ETH -- --%
Fear & Greed F&G 54 Neutral
ESC
Type to search articles
Electrum Showed Users a Payment They Never Made, Then Let Them 'Speed It Up.' Bumping the Fee Sent the Bitcoin to an Attacker
BREAKING

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

SoftwareElectrum Bitcoin wallet, all versions before 4.8.3
AttackerA malicious Electrum server (the public servers your wallet connects to by default)
TriggerUser manually fee-bumps (RBF) the fake pending transaction
Reports2 user reports; 1 confirmed loss (amount not disclosed)
First reportOctober 11, 2026
Loss reportedOctober 18, 2026
Fix taggedOctober 23, 2026
Fix released + disclosedOctober 24, 2026
Not affectedUsers 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:

  1. You broadcast a real transaction (tx1) through the server.
  2. The malicious server “swallows” it and never relays it.
  3. 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.”
  4. 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.
  5. 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 →

How did this hit?

Discussion

Comments are powered by GitHub. Sign in with your GitHub account to chime in.

Related jobs on Cryptogrind

View all

Looking for your next crypto role?

Browse hundreds of Web3 and crypto positions on Cryptogrind — from smart contract engineers to DeFi analysts.

Browse jobs