Electrum Wallet Fee-Bump Attack Explained: How a Malicious Server Could Steal Your Bitcoin

A critical flaw in Electrum, one of Bitcoin’s oldest standalone wallets, let a malicious server trick users into unknowingly signing away their own funds when they tried to speed up a stuck payment. Electrum’s maintainers disclosed the vulnerability and shipped a fix, version 4.8.3, on October 24, 2026, after at least one user reported losing bitcoin to the exact attack the advisory describes. If you run Electrum and haven’t updated since before that date, this is worth five minutes of your time today.

Here’s exactly how the attack worked, what Electrum’s own advisory says about who was affected, and what to actually check if you’ve used the wallet recently.

What Happened, and When

Electrum published security advisory GHSA-6jp4-8v48-cc5v on October 24, 2026, rating it “high” severity. The advisory, written by core maintainer SomberNight, lays out a timeline:

• October 11, 2026 — a user (credited as “user1”) privately reported the underlying trust issue to the Electrum team. At that point, no one had reported an actual loss from it.
• October 18, 2026 — a second user, credited as “Raju-K12,” privately reported losing funds after using Electrum’s fee-bump feature, confirming the flaw could be exploited for real theft, not just a theoretical issue.
• October 23, 2026 — the fix was tagged into the Electrum codebase, visible on the project’s GitHub release page.
• October 24, 2026 — version 4.8.3 binaries were published and the vulnerability was disclosed publicly.

No CVE identifier had been assigned to the issue as of the advisory’s publication. Electrum did not state a total dollar figure for losses; the public record so far points to at least one confirmed victim.

How the Attack Actually Worked

Electrum is what’s called a lightweight, or SPV (“simplified payment verification”), wallet. Unlike a full Bitcoin node, it doesn’t download and verify the entire blockchain itself — it connects to one of a network of third-party “Electrum servers” and asks that server for information about the blockchain and its own transactions. That convenience is also the exact trust boundary this attack exploited.

According to the advisory, the attack unfolds in a specific sequence:

1. You broadcast a real transaction (call it tx1) — say, a payment to a friend or an exchange.
2. A malicious server you happen to be connected to secretly withholds tx1 from the rest of the Bitcoin network, so it never actually confirms.
3. That same server feeds your wallet a different, conflicting transaction (tx2) that redirects the funds to an address the attacker controls.
4. Tx2 has an invalid signature — meaning it isn’t actually a transaction you authorized — but because of how Electrum’s lightweight design handled unconfirmed transactions, it didn’t check that signature before trusting the server’s report.
5. Your wallet shows tx2 sitting unconfirmed, with no sign that tx1 (the real payment) ever existed.
6. Seeing a stuck, unconfirmed payment, you do exactly what Electrum’s own interface invites you to do: fee-bump it using Replace-By-Fee to get it moving. In doing so, you sign and broadcast tx2 for real — sending your own funds to the attacker.

Two details from the advisory make clear this wasn’t a theoretical lab exploit. First, in the confirmed-loss case, the fake transaction (tx2) was deliberately set with a zero fee — specifically to make it look stuck and nudge the victim into bumping it. Second, in both reported cases, the attacker’s receiving address was “ground” — computer-generated through repeated attempts — to match the last four characters of the legitimate destination address. Bitcoin wallets commonly show truncated addresses in their interface, so a quick glance at the start and end of an address can look correct even when the full address is completely different.

Why This Was Possible: Electrum’s Trust-the-Server Design

Electrum has always documented that it trusts the server it connects to for data about unconfirmed transactions — it’s a known architectural tradeoff that comes with being a light client instead of running a full node. What the advisory describes is less a sudden new flaw and more a documented trust assumption that, in practice, got actively exploited: the wallet accepted a server’s claim about an unconfirmed transaction touching the user’s own coins without verifying that transaction’s signature first.

The fix, landed in commit 90fe308, closes exactly that gap: Electrum now verifies the signature on any unconfirmed transaction that spends an input it considers its own (what the codebase calls “is_mine”) before adding that transaction to the wallet’s local history. A transaction with an invalid signature on a wallet-owned input is now rejected outright, rather than displayed as if it were real.

The advisory is explicit that this fix is narrower than a full solution: it only validates inputs the wallet itself owns. Incoming transactions — payments other people send to you — still aren’t fully validated this way, because doing so would require the wallet to behave more like a full consensus-verifying node, recursively checking any unconfirmed parent transactions too. Electrum’s maintainers also noted they have evidence that some servers were actively exploiting this in the wild, not just that it was theoretically possible.

Vulnerable Versions vs. the Fix

	Electrum before 4.8.3	Electrum 4.8.3 and later
Trusts server’s report of unconfirmed tx on your own coins	Yes, without signature check	No — signature verified first
Invalid-signature transaction can appear in your history	Yes	No, rejected
Risk from a malicious or compromised server	Real, demonstrated with at least one loss	Closed for wallet-owned inputs
Risk if you only ever connect to your own trusted server	Low (you control the server)	Unchanged — still low
Incoming payments from others fully verified	No	Still no — out of scope for this fix
What to do	Update immediately	Keep auto-updates / check for new releases

Who Was Affected and How Much Was Lost

Electrum’s advisory credits two reporters and describes one confirmed loss tied to the attack; it does not publish a running victim count or a total dollar figure, and no broad campaign scale has been confirmed publicly as of this writing. That makes this a different kind of story than a nine-figure exchange hack — it’s a serious, high-severity design flaw with at least one real victim, caught and fixed before (as far as the public record shows) it was mass-exploited.

The advisory also notes an important boundary: if you only ever connect your Electrum wallet to a server you run yourself or otherwise explicitly trust, you were never exposed to this specific attack, since the whole exploit depends on a server deliberately lying to your wallet. The risk sits with Electrum’s default behavior of connecting to servers from its public server list, where you generally don’t know who operates the one you land on.

What to Do Right Now

• Update to Electrum 4.8.3 or later immediately, downloading only from electrum.org or Electrum’s official GitHub releases, and verify the download’s signature if you know how.
• Before approving any fee bump (or any transaction), manually check the full destination address and amount — not just the first and last few characters, which this attack specifically exploited.
• If you recently bumped a stuck transaction’s fee and the destination doesn’t match what you intended, treat it as a likely theft: check the transaction on a block explorer, and if anything is wrong, move remaining funds to a new wallet with a newly generated seed phrase.
• Consider running or connecting to a server you control or trust, if you’re a frequent Electrum user, which removes this entire category of risk going forward.

The Bigger Pattern

This is the second major wallet-security story in Bitcoin and crypto’s past few weeks that has nothing to do with a careless user clicking a phishing link, and everything to do with a trust assumption built into the software itself. It’s a useful contrast to the Ledger CryptoBilis hardware implant, where attackers physically tampered with devices before they reached buyers, and to the MetaMask staking incident from late September, a software infrastructure problem on the exchange and protocol side. The Electrum case sits in a third category: a wallet that works exactly as designed, exploited through a trust relationship — between your software and the server it talks to — that most users never think about until it’s used against them.

None of this means light wallets like Electrum are unsafe to use; they remain far more practical for most people than running a full Bitcoin node. It does mean the habit worth building is the same one security researchers have recommended for years and that this incident makes concrete: read the full destination address before you sign anything, especially a fee bump on a payment you didn’t expect to get “stuck.” This isn’t financial advice — it’s software security hygiene, and it costs you nothing but a few extra seconds.