The developers of the Bitcoin wallet Electrum have patched a high-severity Electrum wallet vulnerability that was already being exploited. Malicious servers could intercept a just-broadcast transaction, replace it in the wallet with a fake one and trick users into signing a payment to the attacker when they bumped the fee with Replace-by-Fee (RBF). At least one user lost money. The fix is version 4.8.3, released on October 24, 2026.
This article explains, without the drama, how the attack works, who is affected and what you should do now.
Key Takeaways
- All Electrum versions before 4.8.3 are affected. The developers rate the issue as “High”.
- According to the advisory, some servers are already performing the attack “in the wild”. There were two reports, and one user lost money.
- The trick: the server hides the real transaction and shows a fake one paying the attacker’s address. Anyone who then bumps the fee signs a valid payment to the attacker.
- Version 4.8.3 now verifies the signatures of the wallet’s own inputs in unconfirmed transactions.
- Users who only connect to servers they trust, such as their own, are not affected.
What we know about the Electrum wallet vulnerability
Electrum is a light wallet: it does not download the full blockchain but fetches transaction data from external servers. The client verifies confirmed transactions itself using Simple Payment Verification (SPV). Unconfirmed transactions in the mempool are a different story. The official Electrum FAQ states explicitly that the server is trusted about unconfirmed transactions. That is documented design, not a hidden secret.
What is new is that someone found a practical way to abuse that trust. The security advisory GHSA-6jp4-8v48-cc5v describes the attack in four steps:
- The user broadcasts a new transaction (“tx1” in the advisory). The malicious server the client uses as its main server does not relay it but “swallows” it.
- Instead, the server updates the wallet’s history with a conflicting transaction (“tx2”) whose outputs are replaced with the attacker’s address.
- tx2 carries invalid signatures. This went unnoticed because the light client did not check them. The wallet shows tx2 as unconfirmed, while the real tx1 is not displayed.
- If the user then manually bumps the fee of tx2 via RBF, Electrum signs a new, this time valid version with a higher fee. The money goes to the attacker.
The key point: the fake transaction alone cannot move any coins because its signatures are invalid. It only becomes dangerous once the user re-signs it. That is exactly what the attack is built around.
How the attackers cover their tracks
The advisory shares details from the two reports that show how deliberate the attackers are:
- Matching address endings: In both cases the attacker’s address was ground so that its last four characters matched those of the legitimate destination. A quick glance at the end of the address does not reveal the swap.
- Zero fee: Based on the second user’s report, the server built the fake transaction with no fee at all. The developers assume this was meant to make the payment look stuck and prompt the user to bump it.
- Withheld transaction: The first user reported that the real transaction never propagated over the Bitcoin peer-to-peer network, meaning the server held it back.
According to a CoinDesk report, the first case involved a 2-of-3 multisig wallet with two hardware wallets on which the user had checked the legitimate payment. The user later noticed a different outgoing transaction in the history but did not report a loss. The developers have not disclosed how much the second user lost or which servers were involved. Note that in this scenario a hardware wallet only helps if you compare the full destination address shown when signing the fee bump with the one you intended.
Disclosure timeline
The advisory documents the sequence of events:
- October 11, 2026: The first user sends a private disclosure. The fee-bump attack vector is not yet recognized at that point.
- October 18, 2026: The second user (Raju-K12) privately reports losing money after a fee bump.
- October 23, 2026: Version 4.8.3 containing the fix is tagged in Git.
- October 24, 2026: The 4.8.3 binaries are released and the issue is disclosed publicly.
Six days passed between the report of the loss and the release of the fix. For an open source project, that is a quick turnaround.
What version 4.8.3 changes and where limits remain
According to the advisory, the client now verifies the signatures of all inputs that belong to the wallet (“is_mine”) before adding an unconfirmed transaction to its local history. A fake outgoing payment with invalid signatures is therefore no longer displayed. The Electrum 4.8.3 release notes list the issue as “sev-high” and mention further security fixes based on reports from four people in total, without describing them in detail.
The developers are upfront about what the fix does not cover:
- Only inputs from the wallet’s own addresses are checked. Incoming unconfirmed transactions are still not validated.
- The client lacks a full consensus engine. To cover inputs it does not own, it would have to validate unconfirmed parent transactions recursively until it reaches mined ones.
- Mined transactions are still verified via SPV, as before.
In practice this means that an unconfirmed incoming payment shown in a light wallet is no proof that the money will actually arrive. That has always been true, but this case is a useful reminder.
What Electrum users should do now
- Update to 4.8.3: This is the most important step. Only download the new version from the official website and verify the file signature, as the project recommends.
- Check every signature: Until you update, the advisory advises verifying output addresses and amounts in full whenever you sign a transaction, whether it is a fee bump or not. Not just the last few characters.
- Be suspicious of “stuck” payments: If a transaction you did not create shows up in your history, or a payment is stuck with zero fee, do not bump the fee. Check the outputs first and cross-check with a block explorer.
- Use your own server: According to the advisory, clients connecting to servers they trust, such as their own, are not affected. For larger amounts, running your own node with an Electrum server is worth considering.
Our take
The case follows a familiar pattern: a design trade-off is tolerated until someone finds a practical attack. Electrum never hid the fact that it trusts the server for unconfirmed transactions. But the attack only worked through a combination of a withheld transaction, a faked display, a look-alike address and the convenience of fee bumping. In the end, the human remains the last line of verification.
We have seen similar patterns recently: in the Ledger hardware wallet hack via tampered devices, the Qubic hack caused by weak wallet seeds and the 10-year-old XRP Ledger security bug. The lesson is similar every time: keep software up to date and look closely before you sign.
Conclusion
The Electrum wallet vulnerability is serious because it was exploited and cost real money. It is also manageable: version 4.8.3 detects fake outgoing transactions, and anyone who checks every destination address in full can spot the trick even without the update. If you use Electrum, update today. We will keep you posted if more details about the attackers or the size of the losses emerge.
