Electrum users who try to speed up a stuck Bitcoin transaction may unknowingly sign a payment to an attacker. On October 24, 2026, the Electrum development team published security advisory GHSA-6jp4-8v48-cc5v alongside version 4.8.3, describing how a malicious server can replace a just-sent transaction with a fraudulent one and wait for the user to bump the fee via Replace-by-Fee. Two reports reached the developers before the patch shipped; one involved a confirmed loss of funds.
We reviewed the advisory published on GitHub by developer SomberNight, the official Electrum website and its FAQ, and coverage by The Defiant and The Crypto Basic. The advisory does not disclose the amount lost or the number of malicious servers involved.
New release: Electrum 4.8.3. This release fixes a critical security issue, so we urge all users to upgrade. A description of the vulnerability will be published later today. (note: Windows Defender may show a warning about ZXing.dll, ignore that, it is a false positive)
— Electrum (@ElectrumWallet) October 24, 2026
How the Attack Works
Electrum is a lightweight self-custody wallet: private keys never leave the user's device, but the client relies on external servers to fetch balances and transaction history instead of downloading the full blockchain. When a user broadcasts a transaction (call it tx1), a malicious server can simply refuse to relay it to the Bitcoin network. It then pushes a different transaction (tx2) into the wallet's history, one that spends the same funds but pays an address controlled by the attacker. The wallet displays tx2 as unconfirmed and tx1 disappears entirely. Critically, per the advisory, the wallet does not verify the signatures on tx2 because lightweight clients were never designed to do so.
The trap closes at the next step. According to the advisory, tx2 carried a zero fee, so it sat unconfirmed and invited the user to accelerate it. Replace-by-Fee is the mechanism that replaces an unconfirmed transaction with a higher-fee version: applying it causes Electrum to broadcast a brand-new, fully valid transaction with tx2's recipients, and the attacker's payment goes through. Think of it as a postal worker pocketing your letter the moment it drops in the box, filing a copy addressed to someone else, and then waiting for you to pay the express-delivery surcharge.
Why a Server Can Fool the Wallet
Electrum's own FAQ addresses the question of server trust with what it calls a short answer: “Not quite.” The client never sends private keys to servers and does verify data about confirmed transactions using Simple Payment Verification, which checks inclusion proofs against block headers. But the FAQ contains an explicit carve-out: the server is trusted for unconfirmed transactions. Electrum typically connects to around ten servers simultaneously, yet one acts as the primary server, and that is the single point through which this attack passes. Users who run their own server or connect to a trusted one are not exposed, according to the advisory.
How Serious Is It?
The advisory rates the flaw as high severity and does not assign a CVE identifier. The development team stated that some servers were already running the attack at the time of disclosure. Two reports were filed. The first user noticed an unfamiliar transaction in the wallet history while the genuine transaction never reached the Bitcoin network; that user was running a 2-of-3 multisig wallet, and the fake transaction replicated all 31 inputs of the real one. The second user bumped the fee on the fake transaction and lost funds, an amount the advisory declines to specify.
One detail reveals how carefully the attack was crafted: the attacker's address had been generated to share the same last four characters as the legitimate destination address. Anyone who checks only the tail of an address would notice nothing wrong. It is the same principle behind clipboard-hijacking malware that swaps copied addresses for visually similar fakes.
What Changes in Version 4.8.3
The fix included in 4.8.3 makes the client verify signatures on wallet-owned inputs in every unconfirmed transaction before adding it to the history. A fraudulent transaction that spends the user's funds without valid signatures is now discarded. The check covers only inputs belonging to the wallet; incoming transactions from third parties are not verified. That would require a full consensus engine, the advisory explains. The first report arrived on October 11 and the second, the one involving a loss, on October 18. Version 4.8.3 was tagged on October 23 and released alongside the advisory on October 24.
What Electrum Users Should Do
The first action is to update to version 4.8.3, downloaded exclusively from electrum.org as the official site recommends. To verify the GPG signature before installing. Users who can't update immediately should verify the full destination address and amount every time they sign a transaction, including any fee bump, as the advisory instructs. If the wallet history shows a different transaction from the one just signed, do not accelerate it. Our practical recommendation: compare the entire address, not just the last few characters. With a hardware wallet, read the address on the device's own screen, on a unit purchased through official channels. The risk of tampering on third-party resellers is real, as the case of modified Ledger devices sold by third-party vendors demonstrated.
Watch out for unsolicited support contacts. The official Electrum website warns that anyone reaching out privately claiming to be wallet support is almost certainly an impostor trying to steal bitcoin. It's the same playbook used in scams that impersonate exchanges and regulatory authorities to get users to hand over their crypto.
Has This Happened Before?
Malicious servers have targeted Electrum before. According to Malwarebytes, starting in late December 2018 a network of rogue servers exploited a flaw in versions prior to 3.3.3 to display fake upgrade prompts and trick users into installing backdoored wallets. Malwarebytes estimated that more than 771 bitcoin were stolen. The development team responded by using a vulnerability in older clients to force an update push, and in April 2019 Electrum's servers came under DDoS attacks from more than 25,000 IP addresses.
Electrum 4.8.3: What's Confirmed, What Isn't
A quick reference before deciding whether to act:
- Confirmed: Security advisory GHSA-6jp4-8v48-cc5v published October 24, rated high severity; all versions prior to 4.8.3 are affected; two user reports filed, one with confirmed fund loss; fix ships in 4.8.3; users running their own or a trusted server are not exposed.
- Not disclosed: Amount of funds lost, number and identity of malicious servers, total users affected, CVE identifier.
- To watch: Adoption pace of the 4.8.3 update, any additional loss reports, and whether other wallets connecting to Electrum servers will add similar signature checks for unconfirmed transactions.
The Bigger Picture
This attack targets a dimension of self-custody that rarely gets discussed: not the private keys, which stayed safe throughout, but the information the wallet presents to the user. It works by exploiting two routine behaviors: bumping a stuck transaction and spot-checking only the last characters of an address. Beneath both behaviors sits a layer of invisible trust, the server. The same structural flaw appeared in a very different context, the Revolut case where a fake government request deceived a regulated institution: a source that looks authoritative but isn't.
The signals worth tracking now are how quickly users update to 4.8.3, whether further losses surface in the coming days, and whether other lightweight wallets that rely on Electrum servers introduce equivalent checks on unconfirmed transactions. For anyone who holds their own bitcoin in self-custody, one rule applies: verify everything you sign, in full, every time.
