Vulnerabilities

Electrum, the long-running desktop and Android Bitcoin wallet, released version 4.8.3 on October 24, 2026 to fix a high-severity flaw that some public Electrum servers are already using against people. A malicious server can hide a payment the user just sent, show a fake one in its place that pays the attacker, and wait for the user to "speed it up" with a fee bump. The fee bump produces a valid, signed transaction to the attacker.

Every Electrum version before 4.8.3 is affected. The developers published the issue as GitHub advisory GHSA-6jp4-8v48-cc5v, with no CVE assigned. They received two private reports, and in one of them the user lost money. If you or your finance team hold bitcoin in Electrum and connect to public servers, which is the default, upgrade today and do not bump the fee on any pending payment until you have.

How it works

Electrum is a light client. It does not download the blockchain; it asks an Electrum server for the transactions that touch the wallet's addresses. For confirmed transactions the wallet checks the server's answer against block headers, so a server cannot invent a mined payment. Unconfirmed transactions, the ones still waiting in the mempool (the queue of transactions not yet in a block), have no such proof. Electrum documents that the wallet trusts its main server for this mempool data.

The advisory describes how a hostile server abuses that trust:

1. The user sends a payment, transaction A, and the wallet hands it to the server to broadcast.
2. The server never relays it. Instead it reports a different transaction, B, that spends the same coins but pays an address the attacker controls.
3. Transaction B carries invalid signatures. It could never be mined, but older clients did not check signatures on unconfirmed transactions, so the wallet shows B as a normal pending payment and hides A because the two conflict.
4. The payment looks stuck. If the user uses Replace-By-Fee (RBF), the Bitcoin feature that lets you re-sign a pending transaction with a higher fee, Electrum takes B as the starting point and signs a new version of it with valid signatures.

That new version pays the attacker, and it is perfectly valid. It confirms, and the coins are gone. The user never typed the attacker's address; they only clicked to raise a fee on what looked like their own payment.

What attackers are doing

The developers say some servers are running this attack now. The two reports show how the attackers make it work:

• The attacker's address was ground, meaning generated by brute force, so that its last four characters matched the address the user meant to pay. A quick glance at the end of the address in the fee-bump dialog would pass.
• One fake transaction had a fee of zero. A payment that never confirms pushes the user towards a fee bump, which is exactly what the attacker needs.
• In one case the real transaction never reached the Bitcoin peer-to-peer network at all, so the server had simply kept it.

The timeline from the advisory: a user named dannydeezy reported a swapped transaction privately on October 11, before anyone had worked out the fee-bump angle. On October 18 a second user, Raju-K12, reported losing money after bumping a fee. The fix was tagged on October 23, and binaries and public disclosure followed on October 24. No source gives a loss amount or a count of malicious servers.

What 4.8.3 changes, and what it does not

The fix is in commit 90fe308. Before a mempool transaction is added to the wallet's history, Electrum now verifies the signatures on every input that spends the wallet's own coins. A forged transaction B that claims to spend your coins without your signature is rejected, and transactions that turn out to be invalid are removed from local history along with anything that conflicts through them.

The developers are clear about the limit. Only inputs the wallet owns are checked. Incoming payments from other people are still taken on the server's word while unconfirmed, because checking them fully would need a consensus engine and recursive checks of unconfirmed parent transactions, which Electrum does not have. So a malicious server can still show you an incoming payment that never arrives. Treat any unconfirmed incoming transaction as unpaid until it has confirmations.

What to do

1. Upgrade to Electrum 4.8.3 on every desktop and Android install. Download it only from electrum.org and verify the GPG signatures that ship with each release before running it.
2. If you cannot upgrade today, do not use Increase fee or any other RBF action. If you must sign anything, read the full destination address and the amount in the signing dialog and compare every character with the address you were given, not just the first and last few.
3. Where you can, use a server you control. Clients connected to a trusted server, such as your own, are not affected. In the desktop app that is Tools, Network, where you can untick automatic server selection and enter your own server; from the command line, electrum --oneserver --server <host>:<port>:s keeps the wallet on that one server.
4. Check whether you were already hit. For every payment you fee-bumped in Electrum before upgrading, look up the transaction ID on an independent block explorer and compare its outputs, character by character, with the address you intended to pay. Also look up the transaction you originally sent. If it never appears on any explorer, the server held it and the recipient was never paid.
5. After upgrading, open the wallet's history again. A fake pending payment should no longer appear. Pay anyone who was not paid from the restored balance.

For a business, the practical rule is that a wallet's view of unconfirmed transactions is only as honest as the server feeding it. Treasury and payment procedures should require a second check of the destination address on an independent source before any signature, including fee bumps, and should not count unconfirmed incoming payments as received.

The wider lesson

The root cause was a documented trust assumption. Electrum always said it trusted its server for the mempool. What nobody had modelled was a feature, RBF, that turns server-supplied data into something the user signs. Any client that signs transactions or requests based on data from a remote party it does not control has the same question to answer: what happens if that party lies? It is the kind of question we ask in a red team and code review, and closing the gaps it finds is part of our safeguarding and hardening work. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Electrum advisory GHSA-6jp4-8v48-cc5v, Electrum release notes, Electrum fix commit 90fe308, Bitcoin.com News, The Cryptonomist.