
Malicious Electrum servers have been swapping users’ outgoing Bitcoin payments for fake, zero-fee lookalikes, hoping the owner would bump the fee and sign a real payment to the attacker.
Electrum developer SomberNight disclosed the issue in an October 24 security advisory, saying some servers are carrying out the attack in the wild.
The attack needs the owner’s signature
A malicious server cannot spend anyone’s Bitcoin on its own. The fake transaction it plants carries invalid signatures, so the network would reject it. What the attacker needs is a valid signature from the wallet owner, and the trap is built to get one through a fee increase.
Replace-by-fee, or RBF, speeds up a pending Bitcoin payment by replacing it with a new version that pays a higher fee. To the user, it feels like adjusting a setting. To the network, it is a brand-new transaction, and signing it authorizes every destination and amount inside it. If the transaction being “bumped” has already been altered, the new signature approves the altered version.
The bait is a payment that appears stuck. In the case where a user lost money, the server built its fake with a zero fee, which developers believe was meant to prompt a fee bump. A transaction with no fee sits unconfirmed, and bumping the fee is the standard response.
How a malicious server set the trap
Electrum is a light wallet: it does not download and check the whole blockchain itself. Its documentation says it typically connects to about ten servers but relies on one main server for transaction history and broadcasting. The others mainly supply block headers and fee estimates. The advisory notes that trusting the main server with unconfirmed transactions is part of Electrum’s documented design. What is new is a practical way to turn that trust into theft.
| Step | What happens |
|---|---|
| 1. Swallow | The user broadcasts a payment. The malicious main server never passes it to the Bitcoin network. |
| 2. Swap | It feeds the wallet a conflicting transaction that spends the same coins to the attacker. The signatures are invalid, but affected versions did not check them for unconfirmed transactions. |
| 3. Display | The wallet shows the fake as an unconfirmed payment. The real one disappears from history. |
| 4. Bump | If the user raises the fee on the fake, Electrum signs a valid replacement that pays the attacker. |
Until step four, nothing has been lost. As Coindoo has explained before, a valid digital signature can authorize the wrong payment if the transaction presented for signing has been changed. That is exactly what the fee bump supplies.
What the two victims saw
The first report came from user dannydeezy on October 11. The payment was sent from a 2-of-3 multisignature wallet secured by two Trezor hardware devices, combining 31 inputs into one output. The user checked the destination on both Trezors, then broadcast. Electrum’s history then showed the full amount heading, unconfirmed, to an unknown address, before the entry changed to “Local.” Nothing ever reached the mempool.
The fake was carefully built. It used the same inputs and copied the real transaction’s signature data byte for byte, so all 62 signatures matched the genuine payment and none matched the fake. It sent almost everything to an address ending “GyQ3,” the same four characters as the real destination, and a small amount back to one of the wallet’s own addresses, mimicking a normal change output. The fee was close to zero. Because the user did not sign again, the real transaction was still valid and unbroadcast, and no money was lost.
Developers did not identify the fee-bump route until a second user, Raju-K12, reported on October 18 that they had lost money after bumping the fee on a fake transaction. The amount was not disclosed.
Oct 11: First private report, without the fee-bump angle
Oct 18: Second report, after a loss from a fee bump
Oct 23: Version 4.8.3 tagged with the fix
Oct 24: Binaries released and advisory published
What 4.8.3 fixes, and what it doesn’t
The fix makes Electrum verify signatures on any unconfirmed transaction that spends coins from the wallet’s own addresses before adding it to history. A fake outgoing payment with invalid signatures is now rejected instead of displayed, which closes this attack.
The check is deliberately narrow. Incoming unconfirmed transactions are still not validated, and the advisory explains why: Electrum has no full consensus engine, and checking other people’s inputs would mean tracing their unconfirmed parent transactions back until reaching ones already mined. Confirmed transactions were already verified through simplified payment verification, which checks them against block headers.
Users who connect only to servers they trust, such as their own, were not affected. That exemption does not extend to whichever public server a wallet happens to pick as its main connection.
Before you sign anything again
1Update to 4.8.3 from Electrum’s official website, and verify the download signature using the instructions there.
2Check the full address against the original invoice or payment request, not against wallet history, which is what the attacker controls.
3Confirm amounts and fee on the device screen for every new signature. Trezor’s RBF guide and sending guide both ask users to check the updated details there.
4If a payment looks stuck or changed, stop. Look up the original transaction ID on an independent block explorer before bumping anything. In the first report, the real payment had never reached the network.
Anyone who cannot update yet has a workaround in the advisory: whenever signing any transaction, fee bump or not, check that the output addresses and amounts are exactly as expected. The patch closes this specific route, but Electrum still relies on its main server for unconfirmed data, so the screen where a payment is approved remains the final check.
This article is provided for informational purposes only and does not constitute financial or investment advice.



Be the first to comment