Electrum's Fee-Bump Bug: What Broke, Step by Step

Here is a walkthrough of the Electrum fee bump bug that got patched this week, step by step, so you can see exactly where it broke and check whether it touched you.

Step 1: The Payment You Thought You Sent

You open Electrum, your Bitcoin wallet talks to a server to see the network, and you send a payment. Electrum, like most lightweight wallets, does not run a full Bitcoin node itself. It connects to a server, often one you did not choose yourself, to learn what the mempool and the chain look like. Most of the time that server just relays what is true. The Electrum fee bump bug showed what happens when it does not.

The flaw, tracked as advisory GHSA-6jp4-8v48-cc5v and published by Electrum developer SomberNight on October 24, 2026, lived in how Electrum treated a transaction that was still sitting unconfirmed in the mempool. Electrum's own advisory rates it high severity and says some servers were already exploiting it. It turned on Replace-By-Fee (RBF), the Bitcoin feature that lets you reissue a pending payment at a higher fee if it is taking too long to confirm. RBF is a normal, useful tool. The bug turned it into a lever a bad server could pull.

Step 2: The Server That Held It Back

When the wallet broadcast a new payment, a malicious server could swallow it instead of passing it on to the Bitcoin network. In its place, the server updated the wallet's history with a different, conflicting transaction that spent the same coins but paid the attacker's address. That fake carried invalid signatures, and the old Electrum did not check them, because by design it trusted its server about unconfirmed transactions.

Two details made the swap hard to spot. According to the advisory, the attacker's address was ground to match the last four characters of the real destination, so a quick glance at the end of the address looked right. And in the case where money was lost, the fake transaction carried a zero fee, so it sat there looking stuck.

At this point nothing has been stolen yet. The wallet simply has a distorted picture of what is pending, fed to it by a server it trusted to tell the truth.

Step 3: The Fee Bump That Finished the Job

This is where the bug did its damage. When the user, seeing their payment apparently stuck, used Electrum's fee-bump feature to speed it up, the wallet signed a higher-fee version of the attacker's substituted transaction. The fake had invalid signatures, but the replacement the wallet built carried real ones, made with the user's own keys. That valid replacement paid the attacker.

The advisory's timeline shows two private reports. The first, on October 11, came from a user who noticed after broadcasting that the wallet history showed a different transaction than the one sent; that user did not report a loss. The second, on October 18, came from a user credited as Raju-K12, who bumped the fee on a swapped transaction and lost money. The amount has not been disclosed.

Step 4: The Electrum 4.8.3 Fix, and What It Actually Checks

The fix, in commit 90fe308, was tagged in version 4.8.3 on October 23, 2026, and the binaries shipped on October 24 alongside public disclosure. The wallet now verifies the signatures on inputs it owns in any unconfirmed transaction before adding that transaction to its local history. In plain terms, an unconfirmed transaction spending your coins has to be one your keys actually signed, rather than whatever version a server hands over.

The project is open about what remains. Even with the fix, Electrum validates only inputs that pay from addresses the wallet owns, so incoming unconfirmed transactions from other parties are still not checked, because the lightweight client has no full consensus engine or script interpreter the way a full node does. The fix closes the fee-bump path; it does not turn Electrum into a full node. Electrum's own security advisory on GitHub lays out the attack, the fix and the timeline in full.

The advisory also narrows who was actually at risk. People whose wallet connects only to a server they trust, such as one they run themselves, were not affected, because their own server had no reason to lie to them. Anyone on an older version connected to a public server was the one left exposed, if that server turned out to be malicious.

Step 5: What to Check on Your Own Electrum Wallet

If you use Electrum, four things are worth doing in order. First, confirm your version is 4.8.3 or later; the fix does nothing for a wallet still running old code. Second, before you sign anything, a fee bump or a fresh payment, read the whole output address and the amount, not just the last few characters, which is exactly the workaround Electrum gives for anyone who cannot upgrade yet. Third, if you can point the wallet at your own Electrum server rather than a public default, do it, since it removes the party that would need to lie to you in the first place. Fourth, treat any pending payment that looks "stuck" with more suspicion than usual before you reach for the fee-bump button, and check it against a block explorer you trust rather than against the wallet's own display.

The wider lesson is about trusting a message layer, not just a wallet. The same logic applies to a mining pool telling you what it credited your rig, which is one reason NexusPool signs an hourly Glass Ledger receipt for the shares and difficulty it counted from every rig, rather than asking a miner to take its word for it.

What This Bug Is, and What It Is Not, for NexusPool Miners

This is not a NexusPool story in a direct sense. NexusPool does not build or operate Electrum, and nothing here suggests NexusPool's own Stratum V1 and Stratum V2 handling was touched by this flaw. The connection is the pattern: a party that stands between you and the truth of what happened to your coins or your shares can be wrong, honestly or otherwise, and a system worth using lets you check instead of trusting its word. For a miner, that same instinct is why NexusPool built a tool to show the exact coinbase that would pay your address on the current block, before you've found anything, so there is nothing to take on faith about where a reward would go.

To be clear about what this post does not claim: this was a wallet software bug in Electrum, not a flaw in Bitcoin's protocol, not a mining-pool incident, and not evidence that any other wallet is safe or unsafe by association. Nothing here is investment advice, and holding or moving bitcoin carries risk regardless of which wallet or server you use.

Check this first: version 4.8.3 or later, the full address and amount before every signature, and whether you are pointed at a server you actually trust. Everything else in this walkthrough follows from those three facts.

Trust nothing. Verify that the transaction your wallet is about to sign is the one you actually meant to send.