Electrum 4.8.3 is the patch you install before the next fee bump, not a seed-phrase scare. On 24 October 2026 at 12:52 UTC the wallet project published GHSA-6jp4-8v48-cc5v, a high-severity advisory: a malicious Electrum server can hide a just-broadcast Bitcoin transaction, show a conflicting fake in history, and try to get the user to replace-by-fee (RBF) it toward an attacker. Binaries for 4.8.3 went out the same day. The current download on electrum.org lists Electrum-4.8.3 as latest.
This is not a remote drain of a hardware seed. It is a server that the light client already trusts for unconfirmed data, used in a way the project now says is happening in the wild. Two private reports came in. One user lost money after bumping the fake. Bitcoin (BTC) on our CoinGecko snapshot was $80,839 (24h −0.31%) as of 2026-10-24T23:58:55+00:00. The tape can wait. The wallet version cannot.
What happened
Electrum tagged 4.8.3 on 23 October 2026 and released signed binaries on 24 October, then opened the advisory. Vulnerable builds are those below 4.8.3. The patched version is 4.8.3. There is no CVE number on the GitHub advisory as of this writing.
The sequence in the disclosure is ugly and specific. The client broadcasts a real transaction (call it tx1). A hostile server can swallow that broadcast so it never hits the public Bitcoin peer network. It then feeds the wallet a conflicting unconfirmed record (tx2) that rewrites outputs toward an attacker address. Signatures on tx2 can be invalid. The light client did not check them before putting that record in local history. The wallet then shows tx2 as the unconfirmed spend. tx1 disappears from the screen. If the user fee-bumps what they see, they sign a higher-fee version of the fake and pay the attacker.
The project says some servers are already doing this. User1 (reported privately on 11 October 2026) saw history flip to a different destination after broadcast; the real payment never reached the mempool. User2 (18 October) bumped the fake and lost funds. Both said the attacker’s output was ground so the last four characters matched the real destination. User2’s fake was built with roughly zero fee, which is the bait for an RBF click. The fix commit is in 4.8.3: the client now verifies signatures on wallet.is_mine inputs for mempool transactions before adding them to local history.
Electrum’s own FAQ has long said the main server is trusted for unconfirmed transactions. That is a documented design choice, not a hidden backdoor. What changed is a practical trick that turns that trust into a fee-bump trap. Clients that talk only to a server they run themselves are called out as not affected. Everyone else on an old binary is.
Context
Electrum is a Bitcoin wallet that keeps keys on the user side and asks servers for history, rates, and broadcast. That split is why it stays light. It is also why an unconfirmed line in the UI is not the same as a mined output on a full node. Replace-by-fee is a normal Bitcoin tool: you sign a new transaction that spends the same inputs with a higher fee so miners prefer it. The advisory is about signing the wrong unconfirmed object, not about RBF itself being broken.
I keep this on the Bitcoin beat because the failure is in how a widely used BTC desktop and Android client paints unconfirmed spends. It is not an Ethereum fee-market story and it is not an exchange outage. Self-custody still means you hold the keys. It does not mean the history pane is gospel before a transaction is in a block. Our wallet safety guide starts with download source and signature checks for a reason. electrum.org is repeating that warning in the usual place: do not grab the installer from a random mirror.
The 4.8.3 notes also bump certifi so the runtime distrusts revoked eMudhra/emSign certificates. That is a separate hygiene item sharing the same tag. The lead issue remains GHSA-6jp4-8v48-cc5v. The project is explicit that even after the patch it still only validates inputs it considers its own. Incoming unconfirmed payments are not run through a full script interpreter. Mined transactions already get SPV-style checks. If you needed a reminder that “shown as unconfirmed” is not “settled Bitcoin,” this is it.
Weekend tape does not change the upgrade math. BTC was still in the same $80k neighborhood on that snapshot, with global market cap about $2.73 trillion and Bitcoin dominance about 59.50%. A wick on a spot venue is a different file. This file is: which Electrum binary is running when someone hits bump fee. For the longer Bitcoin cycle notes, see our Bitcoin history page. For more desk copy in this lane, use the Bitcoin news category.
Our read
My stance: treat 4.8.3 as mandatory for any Electrum instance that does not talk exclusively to a server you operate. Treat it as a history-trust bug, not a seed drain. The seed never had to leave the device for user2 to lose money. The user signed. That is the whole trick.
I am not going to pretend every Electrum server is hostile. The advisory does not name the live hosts. It does say the attack is in the wild and that one reporter paid. That is enough for me. If you still run 4.8.2 or older, stop using bump fee until you are on 4.8.3. If you cannot upgrade this hour, the published workaround is blunt: before any signature, including a fee bump, check that outputs and amounts are the ones you intended. Matching the last four characters of an address is not a check. It is how the fake was dressed.
Self-custody only works if the thing you sign is the thing you saw on a device you trust. Hardware signing still helps for the first broadcast. User1 was on 2-of-3 legacy P2SH with two Trezors and still saw a poisoned history after clicking Broadcast. The hardware checked the real tx1. The desktop history then lied. The dangerous step is the later RBF on the desktop view of tx2.
Falsifiable claim: By 2026-11-07 23:59 UTC, GHSA-6jp4-8v48-cc5v remains published at that URL with patched version 4.8.3, electrum.org still lists Electrum-4.8.3 as the latest release, and the advisory still states that 4.8.3 verifies signatures on wallet.is_mine inputs for mempool transactions. If Electrum withdraws the GHSA, drops 4.8.3 as current without this fix, or writes that 4.8.3 does not verify those mempool signatures, this read is wrong.
What to watch
First, the binary on disk. Confirm 4.8.3 from electrum.org and verify the GPG signatures the project publishes next to the files. A patched tag with an unsigned installer from a search ad is the old failure mode wearing a new version number.
Second, any follow-up from Electrum that names the hostile servers or adds a CVE. The advisory as of 24 October 2026 12:52 UTC has no CVE. Silence there does not mean the bug is theoretical. It means the public ID is still the GHSA.
Third, your own broadcast path. If you already sent a payment and the history line changed destination, do not bump. The real tx1 may still be valid and unbroadcast, which is what user1 reported. Get onto 4.8.3, then deal with the stuck coins with eyes on outputs, not on a four-character suffix.
Fourth, whether this stays an Electrum-server problem. Light clients that import unconfirmed history from a single host all share a shape. I will not extend the claim to wallets the advisory does not name. I will watch for a second primary from another BTC wallet team. Until then, the actionable list is short: upgrade Electrum, distrust unconfirmed UI, and keep self-custody tied to what you sign, not to what a server paints.