Electrum vulnerability: 4.8.3 fixes rogue-server bitcoin theft

Key takeaways

• Electrum versions before 4.8.3 could be tricked by a malicious server into showing a fake pending transaction that sends the user's coins to an attacker.
• The trap springs when the user "speeds up" that stuck-looking payment with Replace-by-Fee (RBF): the wallet then signs a valid, higher-fee payment to the attacker.
• Electrum rates the issue High severity (advisory GHSA-6jp4-8v48-cc5v). Developers say some servers were already running the attack, and at least one user lost funds.
• Version 4.8.3, released on October 24, 2026, checks signatures on unconfirmed transactions that spend the wallet's own coins.
• What to do now: update from electrum.org, check every output address and amount in full before signing (fee bumps included), and prefer a server you trust or run yourself.

Electrum 4.8.3, released on October 24, 2026, fixes a High-severity Electrum vulnerability that let a rogue server swap a just-sent payment for a fake one, then turn a Replace-by-Fee bump into theft. The GitHub security advisory says attacks were seen in the wild.

Electrum is one of Bitcoin's oldest software wallets. Thomas Voegtlin created it in November 2011, according to electrum.org, and it remains popular with self-custody users, including people who pair it with hardware wallets. The flaw does not break Bitcoin itself. It abuses the trust a light wallet places in the server it connects to.

How the Electrum vulnerability worked

Electrum is a "light" client. It does not download and validate the whole blockchain. It asks public Electrum servers for wallet history and fee estimates, and uses them to broadcast transactions. Confirmed transactions are checked against block headers, but unconfirmed (mempool) transactions reported by the main server have always been trusted. The advisory calls this documented behaviour.

The advisory explains how the attack exploited that trust:

1. The user sends a payment. The wallet broadcasts a real transaction (call it tx1) through its server.
2. The server swallows it. A malicious server does not relay tx1 to the Bitcoin network. In the first reported case, tx1 never propagated over the peer-to-peer network.
3. The server reports a fake. It tells the wallet about a conflicting transaction (tx2) that spends the same coins to an address the attacker controls. Tx2 carries invalid signatures. The advisory notes this "is not checked (due to light client design)."
4. The fake looks stuck. Electrum shows tx2 as unconfirmed and hides tx1. In the reported theft, tx2 had a fee of zero, so it could never confirm. Developers believe this was meant to push the user into bumping the fee.
5. The fee bump completes the theft. When the user clicks to raise the fee with RBF, Electrum builds and signs a new, valid, higher-fee version of tx2. That transaction pays the attacker, and the network accepts it.

The attackers also made the fake hard to spot. In both reports, the attacker's address was generated so its last four characters matched the address the user meant to pay. Anyone who checks only the start and end of an address could miss the swap.

Why Replace-by-Fee was the lever

Replace-by-Fee is a standard Bitcoin feature. It lets the sender swap an unconfirmed transaction for a new version that pays a higher fee. Bitcoin Optech notes that opt-in RBF was defined in BIP125 and first implemented in Bitcoin Core 0.12.0. Fee bumping is routine when the mempool is busy. That is why a payment that looks stuck is effective bait: the user believes they are rescuing their own payment, but they are signing the attacker's version with their own keys.

Timeline: from first report to Electrum 4.8.3

The dates below come from the Electrum advisory and the 4.8.3 release notes, with reporting by CoinDesk and crypto.news.

The fix arrived six days after the first reported theft, CoinDesk noted. The developers have not said how much was stolen, which servers ran the attack, or whether there are other victims, according to CoinDesk and crypto.news.

Who is affected by the Electrum RBF bug

• Affected: every Electrum version earlier than 4.8.3, when the wallet's main server is malicious. By default, Electrum connects to public servers that anyone can run.
• Not affected by this attack: users connected only to a server they trust, such as their own Electrum server, according to the advisory.
• Hardware wallet users are not automatically safe. The device signs whatever the software proposes. A fee bump on a substituted transaction will show the attacker's address on the device screen, so that screen must be read in full. The first report involved Trezor devices, but neither CoinDesk nor the advisory says the hardware was at fault.

What Electrum 4.8.3 changes

The patch (commit 90fe308) makes the client verify the signatures of inputs that belong to the user's wallet in mempool transactions before adding them to local history. A fake transaction that spends your coins with forged signatures is now rejected rather than displayed.

The advisory is open about one limit. Only inputs owned by the wallet are checked. Incoming unconfirmed transactions are still not validated, because full validation would need a consensus engine and recursive checks of unconfirmed parent transactions. A malicious server could therefore still show a fake incoming payment. Treat unconfirmed incoming funds as unconfirmed.

What Electrum users should do now

1. Update to Electrum 4.8.3 or later. Download only from electrum.org. The site warns against other download sources and recommends verifying the GPG signatures on releases.
2. Read every output before signing, including fee bumps. The advisory's workaround for anyone who cannot upgrade is to confirm that output addresses and amounts match what you expect. Check the full address, not just the last few characters, and confirm it on a hardware wallet's screen if you use one.
3. Be suspicious of a payment that suddenly looks different. If your history shows an outgoing transaction you do not recognise, or a stuck zero-fee payment you did not create, do not bump it. Compare it with a block explorer. Our guide to reading on-chain data on mempool.space shows how.
4. Use a trusted or self-hosted server. Electrum lets you choose one server and turn off automatic server selection. People who run a Bitcoin node can run their own Electrum server, which removes this specific risk.
5. Keep your backup safe. This bug does not expose seed phrases. Still, a security scare is a good moment to review how you store your backup. See how to secure a crypto wallet seed phrase.

What it means

The incident shows the trade-off at the heart of light wallets. They are fast and simple because they trust servers for some data, and that trust can be abused. Here the attacker never touched the user's private keys. The user's own wallet signed the theft after being shown a false picture of the mempool. The lookalike address suffix shows the attack was planned, not opportunistic.

For the wider Bitcoin ecosystem, the lesson is about user interface as much as code. Fee bumping is routine because on-chain fees swing sharply from block to block, as the fee data in our Bitcoin halving explainer shows. A routine action is exactly the kind of moment when users stop reading the screen. Electrum's fix closes the specific hole for outgoing payments. Checking every address in full before signing remains the habit that protects funds across all wallets. More coverage is on our Bitcoin and Electrum topic pages.

This article is for information only and is not investment advice.