On this page (7 sections)
Electrum, the Bitcoin desktop wallet, has a critical flaw tracked as CVE-2026-117601. In versions before 4.8.3, a malicious Electrum server can swallow a transaction you just broadcast and show you a different, invalid one that pays the attacker. If you then fee-bump that fake transaction, your wallet signs a real payment to the attacker.
Anyone who uses Electrum with a public or third-party server should care. The project says the attack has been seen in the wild and that at least one user lost money, so this is not purely theoretical. Version 4.8.3 contains the fix.
What happened
Electrum is a light client. It does not download the whole blockchain, so it relies on an Electrum server to tell it about transactions, including unconfirmed ones in the mempool. The project documents that the main server a client connects to is trusted for this. According to the GitHub advisory, someone has now found a practical way to abuse that trust.
When your wallet broadcasts a new transaction (call it tx1), a malicious server can hold it back instead of relaying it. The server then adds a conflicting transaction (tx2) to your wallet history, with the outputs replaced by the attacker's address. Tx2 has invalid signatures, but the client did not check them. Your wallet shows tx2 as an unconfirmed transaction and tx1 disappears from view.
The damage happens only if you act on what you see. If you manually fee-bump tx2 using replace-by-fee (RBF), the wallet signs the new version with a higher fee, and that version is valid and pays the attacker.
Technical details
The root cause is missing signature verification, classified as CWE-347. The fix, in commit 90fe308, makes the client verify the signatures of inputs the wallet owns (the is_mine inputs) on mempool transactions before adding them to its local history.
The maintainers are open about a remaining limit. Even with the fix, only is_mine inputs are validated, so incoming transactions are still not checked. The client has no full consensus engine or script interpreter, and covering other inputs would mean recursively validating unconfirmed parent transactions until it reaches mined ones. Mined transactions are already checked with SPV.
What the in-the-wild reports describe
The advisory says Electrum received two user reports. The first user noticed that after broadcasting, the wallet history contained a different transaction, and found that tx1 had not propagated over the Bitcoin peer-to-peer network, so the server had held it. The second user bumped the fee of tx2 and lost money. According to the advisory, the attacker's address in tx2 was generated to match the last four characters of the legitimate address from tx1, which makes a quick glance at the address unreliable. In the second case the server built tx2 with zero fee, apparently hoping the user would bump it.
These details come from the Electrum maintainers' own advisory. The research available so far shows only one independent publisher, VulnCheck, so the scale of abuse is unconfirmed beyond those two reports.
Who is affected
- Anyone running Electrum earlier than 4.8.3 that connects to a server operated by someone else.
- Users who fee-bump (RBF) a transaction that appeared in their history right after broadcasting.
- Not affected, per the advisory: clients that connect only to servers they trust, for example one they run themselves.
Because the attacker needs to be the server your wallet talks to, the realistic exposure is users on public servers. Running your own server removes that specific trust problem.
How to check your exposure
First find your Electrum version. In the desktop app, the version appears under Help, About. If you installed Electrum with pip, this read-only command prints the installed version; anything below 4.8.3 is vulnerable.
pip show electrumAlso review your recent wallet history. A transaction you did not create, with a zero fee or an unfamiliar destination, or a transaction you just sent that seems to have been replaced, is a warning sign. Check your broadcast transaction ID on an independent block explorer to see whether the network ever saw it.
What to do now
If you installed with pip, this command upgrades the package to the latest release, which includes 4.8.3 or newer. If you use the packaged binaries, download version 4.8.3 or later from the official Electrum project and verify the signatures as you normally would.
pip install --upgrade electrum0 of 6 done
Timeline
| Date | Event |
|---|---|
| 2026-10-11 | First user sends a private disclosure; the fee-bump vector is not yet realized |
| 2026-10-18 | Second user reports privately that they lost money after a fee bump |
| 2026-10-23 | Version 4.8.3 tagged in git with the fix |
| 2026-10-24 | 4.8.3 binaries released and public disclosure |
| 2026-10-27 | CVE published by the National Vulnerability Database |
Why this matters beyond Electrum
The lesson is about trust in a single data source. A light client that accepts unverified data from one server will eventually meet a server that lies. If you build or run software that relies on a remote party for state, verify what you can locally, and train users to confirm critical details out of band before an irreversible action such as signing a payment. For more on keeping small teams and sites safe, see our small business website security guide.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.