Speed up a bitcoin payment without being robbed
In short: on 24 October 2026, the bitcoin wallet Electrum released version 4.8.3 to fix a flaw that was already being exploited: a malicious server could replace your payment with a fake, zero-fee transaction that looked stuck. If you raised the fee to speed it up (the RBF feature), your own wallet signed… the payment to the attacker. At least one user lost funds. If you use Electrum: update (Help > About menu), and until then, don't speed up any transaction. For everyone, one rule: before signing, check the address and the amount, on your hardware wallet's screen if you have one.
Updated on 30 October 2026. This article is not financial advice.
Why a bitcoin transaction gets stuck
When you send bitcoin, your transaction is not written into the blockchain straight away. It first waits in the mempool, the waiting room for unconfirmed transactions. Miners, who produce a block every ten minutes on average, pick first the transactions that pay the highest fees per unit of size.
If you paid too little while the network is busy, your transaction can wait for hours, even days. Nothing is lost: as long as it is unconfirmed, it is not final. But the recipient is waiting for the payment, and you want to unblock it.
Two ways to speed up: RBF and CPFP
| Method | How it works | Who can use it |
|---|---|---|
| RBF (Replace-by-Fee) | You sign a new version of the transaction that spends the same bitcoin but pays a higher fee. It replaces the old one in the mempool. | The sender |
| CPFP (Child Pays for Parent) | You spend an output of the stuck transaction in a second transaction with a high fee; to mine it, the miner must include both. | The recipient, or the sender via the change output |
RBF is the simplest and most widely used: in most wallets, you just right-click the pending transaction and choose "Increase fee". Since version 28 of Bitcoin Core (2024), nodes running it accept by default the replacement of an unconfirmed transaction by a version that pays more, within the replacement rules.
That everyday move is what the attack on Electrum hijacked.
The attack on Electrum, step by step
Electrum is one of the oldest bitcoin wallets, popular because it is lightweight. To stay light, it does not download the whole blockchain: it queries Electrum servers, often run by volunteers, to learn the history of your addresses and to broadcast your payments. For confirmed transactions, it verifies what the server tells it; for unconfirmed transactions, it trusted the server (Forklog, 2026).
Security advisory GHSA-6jp4-8v48-cc5v describes the attack as follows (Electrum, 2026; Safeguard, 2026; TFTC, 2026):
- You sign a payment and click "Broadcast". Electrum hands it to the server it is connected to.
- The malicious server does not relay it to the network. Your real payment therefore exists nowhere.
- It sends your wallet a fake transaction: the same bitcoin spent, but to the attacker's address. For both users who reported the attack, that address ended with the same four characters as the real recipient's.
- Its signature is invalid, but Electrum still shows it in the history as "unconfirmed".
- It pays no fee: it looks stuck. So you raise the fee with RBF… and Electrum signs a new, this time valid, version of the attacker's transaction. It goes out on the network and gets mined.
The key point: no private key was stolen and Bitcoin's cryptography is not at fault. You do the signing, on the basis of falsified information.
Timeline
| Date (2026) | Event |
|---|---|
| 11 October | A first user privately reports that a payment was replaced in his history by another transaction |
| 18 October | A second user reports a loss after raising the fee on a replaced transaction |
| 23 October | Version 4.8.3, which fixes the flaw, is finalised |
| 24 October | Release of the binaries and of the security advisory, rated high severity |
Sources: Chaincatcher (2026); Coin Turk (2026).
The amount stolen and the number of malicious servers have not been published. This is not the first time Electrum servers have been turned against their users: in late 2018 and in 2019, fake servers displayed messages urging people to install a booby-trapped "update" (KuCoin, 2026).
What version 4.8.3 fixes
Electrum now checks the signatures of unconfirmed transactions that spend your own bitcoin before adding them to the history. A fake transaction like the attacker's is rejected before you even see it (TFTC, 2026).
The fix has a limit, which the developers state themselves: incoming unconfirmed transactions are still not verified this way (Forklog, 2026). A malicious server could still make you believe in a received payment that does not exist. An unconfirmed payment is not a received payment, especially if you hand over goods in exchange.
What to do if you use Electrum
- Check your version: Help > About menu on a computer, the app page on Android. Below 4.8.3, you are affected.
- Update from electrum.org only, and check the file's signature if you know how. Windows Defender may flag the ZXing.dll file: the developers say it is a false positive (Forklog, 2026).
- Until then, don't raise the fee on any transaction. Without that step, the fake transaction is just a picture in your history.
- Check your history. An outgoing transaction you don't recognise, or one paying no fee, is suspicious. Compare with a public explorer (mempool.space, for example): if your transaction does not appear there, the server did not broadcast it. And if it does appear, also check the destination address and the amount, not just its presence.
- If you run a Bitcoin node, connect Electrum to your own server: users connected only to a trusted server were not exposed (Bitcoin.com News, 2026).
Other wallets that use Electrum servers are not mentioned in the advisory, which concerns only the Electrum software. If yours works the same way, the question to ask its publisher is simple: does it verify the unconfirmed transactions the server sends it?
Speeding up a payment safely: the checklist
Valid with any wallet, including an up-to-date Electrum:
- Before raising the fee, re-read the transaction: the recipient's full address (not just the beginning and the end), the amount, the change going to your own address.
- On a hardware wallet, read the device's screen, not the computer's.
- Be wary of a zero-fee transaction you did not choose: no serious wallet offers one by default.
- Pay a proper fee from the start: most wallets suggest an estimate based on the desired delay. A well-paid transaction does not need speeding up.
- Keep a record of your payments (date, amount, address, transaction ID): useful in a dispute, and for Belgian crypto taxation, which requires you to be able to justify your transactions.
For large amounts, a hardware wallet remains the best choice; our advice on securing your crypto is in this article. And if you are new to this, our Bitcoin page covers the basics.
True or false?
"The attacker stole Electrum users' private keys." False. The keys stayed with their owners; it was the owners who signed a falsified transaction.
"Bitcoin has a flaw." False. The protocol worked normally. The flaw was in the way Electrum trusted its servers.
"With a hardware wallet, I was safe." Not necessarily. The device signs what it is shown: it only protects you if you check the address on its screen.
"An unconfirmed transaction shown in my wallet is necessarily on the network." False. A server may not have broadcast it, or may display a fake one. An independent explorer lets you check.
"Speeding up a transaction with RBF is risky in itself." False. RBF is a normal Bitcoin feature. The risk came from the transaction being sped up, not from the mechanism.
Test yourself
Disclaimer
This article is for information only and is neither investment advice nor legal advice. The information on the flaw comes from Electrum's security advisory and analyses published by 30 October 2026. Crypto-assets carry significant risks, including total loss.
Sources
Bitcoin.com News. (2026, October). Electrum wallet attack hid bitcoin theft behind a fee increase. https://news.bitcoin.com/electrum-wallet-attack-hid-bitcoin-theft-behind-a-fee-increase/
Chaincatcher. (2026, 26 October). Electrum Bitcoin wallet fixes the theft vulnerability with a fee increase. https://www.chaincatcher.com/en/article/2298911
Coin Turk. (2026, 27 October). Electrum fixes bitcoin theft flaw after rogue server attacks. https://en.coin-turk.com/electrum-fixes-bitcoin-theft-flaw-after-rogue-server-attacks/
Electrum. (2026, 24 October). Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it (GHSA-6jp4-8v48-cc5v). GitHub. https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v
Forklog. (2026, October). Electrum user loses bitcoin in transaction acceleration attempt. https://forklog.com/en/?p=105820
KuCoin. (2026, October). Electrum wallet patches security vulnerability; hackers steal bitcoin. https://www.kucoin.com/news/flash/electrum-wallet-patches-security-vulnerability-hackers-steal-bitcoin
Safeguard. (2026, 25 October). Electrum 4.8.3: malicious server transaction swap via RBF exploited. https://safeguard.sh/resources/blog/electrum-4-8-3-malicious-server-transaction-swap-rbf-exploited
TFTC. (2026, 26 October). Electrum 4.8.3 patches actively exploited RBF fee-bump theft flaw. https://www.tftc.io/electrum-4-8-3-rbf-fee-bump-exploit-patch