On October 24, 2026, Electrum shipped version 4.8.3. The release notes are short, the version number is unremarkable, and the reason it exists is one of the more uncomfortable failure modes in self-custody: a wallet that never leaked a private key still paid an attacker, because the owner signed a transaction the wallet had been tricked into displaying.
Electrum published a security advisory the same day, GHSA-6jp4-8v48-cc5v, rated High, with no CVE assigned. Affected versions are everything before 4.8.3. Two users had already reported it privately, and one of them lost money.
What actually happened
Electrum is a light client. It does not download the whole Bitcoin blockchain. It asks a server for balances, history, fee estimates and mempool contents, then verifies only what it can verify cheaply. Confirmed transactions get SPV-checked against block headers. Unconfirmed transactions, by design, are taken on trust. The Electrum documentation has said so for years.
An attacker took that documented trust and turned it into a trap. The sequence, as described in the advisory:
- You broadcast a normal payment, call it tx1.
- The malicious server swallows it and does not relay it to the network.
- The server updates your wallet history with a different transaction, tx2, whose outputs point to an address the attacker controls.
- tx2 has invalid signatures. Your wallet does not check signatures on unconfirmed transactions from the server, so it displays tx2 as a pending transaction.
- You see a stuck payment and decide to bump the fee. Electrum’s fee bump signs the transaction it believes is pending, which is tx2.
- Your wallet signs tx2 properly, with a higher fee. The network accepts it. The attacker gets paid.
The signature is valid. The transaction is real. It just is not the transaction you thought you were approving.
The four-character trick
The advisory records a detail that makes this far more practical than it sounds. In both reported cases, the attacker’s address was ground so that its last four characters matched the last four characters of the legitimate recipient address. Short address comparisons, the kind people do when a payment is already late, stop working.
In the second report, the substituted transaction paid zero fee. That is not an accident. A zero-fee transaction sits in the mempool looking stuck, which is exactly the condition that makes a user reach for the fee bump button. The trap was built around the user’s next click.
Timeline
The advisory lists it plainly:
- October 11, 2026: the first user reports a transaction replacement privately, without realising the fee-bump path.
- October 18, 2026: a second user, Raju-K12, reports losing money after approving a fee bump.
- October 23, 2026: version 4.8.3 is tagged with the fix.
- October 24, 2026: binaries are released and the advisory goes public.
The stolen amount has not been disclosed. The first reporter noticed the swap before signing anything; the second did not.
What 4.8.3 changes, and what it does not
The fix is commit 90fe308. Electrum now verifies signatures on the inputs that spend the wallet’s own coins before accepting an unconfirmed transaction into its local history. If the parent transaction is already known, the fake transaction is rejected with InvalidTxSignature before it can replace anything. If the parent arrives later, the spending transaction is removed. The commit also handles a subtler point: a txid does not commit to witness data, the same quirk behind transaction malleability.
That closes the path used here. It does not turn Electrum into a full node. The client still validates only is_mine inputs, meaning transactions paying into your wallet from elsewhere are still not script-verified. The advisory says covering those inputs would require recursively validating unconfirmed parents until reaching mined transactions, which is a consensus engine’s job, not a light client’s.
So the boundary has moved, not disappeared. Your wallet now refuses to build a fee bump on top of a fake spend of your own coins. It still trusts a server for a good deal of what it shows you.
What to do
Upgrade to 4.8.3, from electrum.org, and verify the GPG signatures. Then change two habits.
First, treat every signature as a fresh decision. A fee bump is not a maintenance action. It is a new transaction spending the same coins, and it deserves the same address check as the original payment. Open the details, read the outputs, compare the full address, not the first and last four characters.
Second, if you hold meaningful amounts, run your own Electrum server. The attack requires a server that lies. A server you control, reached over Tor or a private link, removes that capability from a third party. This is the same lesson as the Ledger supply-chain mess: the weakest point in self-custody is rarely the key storage, it is the path between what the device signs and what you believe you asked for.
Hardware wallets remain a real defense here, and for a specific reason. When Electrum hands a transaction to a hardware wallet, the device displays the recipient and amount on its own screen. A swapped output address, including the four-character lookalike, has to survive that screen too. Users who blind-sign whatever the host sends lose that check, which is why blind signing keeps showing up in these incidents.
The uncomfortable part
Electrum did not have a bug in the usual sense. It had a trust assumption, documented, known, and load-bearing for millions of users. The attacker did not break cryptography. They read the manual and built a user interface that lied at exactly the moment the user was paying attention to fees instead of addresses.
That is the pattern worth carrying away. In address poisoning, the attacker poisons your history so the wrong address looks familiar. Here, the attacker poisons your pending list so the wrong transaction looks like yours. Both are phishing aimed at the same human shortcut: we verify once, then trust the screen.
Electrum 4.8.3 makes the screen slightly more honest. It cannot make the habit for you.
Frequently Asked Questions
Is Electrum 4.8.3 safe to use now?
For this specific attack, yes. 4.8.3 rejects unconfirmed transactions whose inputs spending your coins carry invalid signatures, so the replaced transaction never reaches your history. You still need to verify recipient addresses on every signature, because the fix only covers inputs that belong to your wallet.
How could a server steal bitcoin without my private keys?
It did not need your keys. It needed you to sign a transaction you had not read. The server hid your real payment, showed a fake pending transaction paying the attacker, and waited. When you bumped the fee, your wallet signed that fake transaction with a higher fee, and the signature was valid.
I already raised a fee on a pending transaction. What should I check?
Open the transaction details and compare every output address and amount against what you intended to send, character by character. If an output address is not your recipient, do not bump again, do not rebroadcast, and move remaining funds to a fresh wallet. Report it to Electrum and to the exchange or recipient if funds are still traceable.
Does running my own Electrum server prevent this?
Yes. The attack depends on a server you do not control lying about mempool contents. If you run your own Electrum server and connect only to it over Tor or a private network, a third party cannot substitute transactions in your history.