Two nearly identical paper receipts on a dark desk, one lit in gold and one in red, joined by a thread of light running from a small unbranded server
Original AI-generated illustration; not a real product.

Electrum 4.8.3 Closes an Attack That Turns a Fee Bump Into a Payment to the Thief

NodeWitness Team 6 min read

The risky moment in this attack is not the payment you send. It is the second signature, when you try to speed up a transaction that looks stuck. Electrum shipped version 4.8.3 on Saturday after at least one user lost funds that way, and the project says servers are running the attack in the wild.

Electrum's official account urged all users to upgrade to 4.8.3 at 10:06 UTC on October 24, describing "a critical security issue" [1]. The advisory published the same day by developer SomberNight sets out how the attack works and confirms it is being exploited [2]. The release notes rate it high severity [3].

Where the trust gap sits

Electrum is a light client. It keeps connections to around ten servers and picks one as its main server, which learns the wallet's addresses, reports its history and broadcasts its transactions [4]. Confirmed transactions are checked with SPV. Unconfirmed ones are taken on the main server's word, a trade-off Electrum documents in its FAQ [4]. The advisory calls it "documented design" and says someone has now found a practical way to exploit it [2].

The attack, step by step

Based on the advisory [2]:

  1. You broadcast a payment. The malicious server swallows it and never relays it to the network.
  2. It pushes a conflicting transaction into your history, spending the same coins but paying an attacker address.
  3. That address is ground to match the last four characters of your real destination.
  4. The fake carries a zero fee, so it looks stuck in the mempool.
  5. You bump the fee with RBF. Electrum signs a replacement with the attacker's outputs and a higher fee, and this time the signatures are valid.

The fake cannot be mined on its own because its signatures are invalid. It only becomes dangerous once the user signs it again to raise the fee [2].

Before 4.8.3, Electrum did not verify signatures on unconfirmed transactions, so the fake showed up as a normal pending payment and the real one dropped out of view [2].

Two reports, one loss

The first private report arrived on October 11 [2]. It came from a user with a 2-of-3 legacy P2SH multisig wallet and two Trezors, sending a 31-input, single-output transaction. The user checked the outputs on both devices and broadcast. The history then showed the full amount leaving, unconfirmed, to an unknown address, and the entry later turned "Local". Nothing reached the mempool [2].

The fake reused the real transaction's inputs, version, locktime and byte-identical scriptSigs. All 62 signatures verified against the genuine transaction and none against the fake [2]. Nearly everything went to the lookalike address, with both ending in "GyQ3", and a small amount went back to one of the wallet's own used addresses. The fee was close to zero [2]. Nothing in the advisory suggests this user lost funds, and the real transaction remained valid and unbroadcast. At that stage, the advisory says, the fee-bump vector had not yet been recognized [2].

On October 18, a second user reported losing money after bumping the fee on the fake [2]. The advisory gives no amount. The fix was tagged on October 23, with binaries and public disclosure following on October 24 [2][5].

What the patch covers, and what it doesn't

Version 4.8.3 verifies the signatures of the wallet's own inputs in unconfirmed transactions before adding them to the local history [2][5]. A forged spend like the ones reported no longer appears as yours.

The advisory is candid about the limits. Only transactions spending the wallet's coins are checked. Incoming unconfirmed transactions are not, because the client lacks a full consensus engine and would have to validate unconfirmed parents recursively back to mined transactions [2]. An unconfirmed incoming payment is still whatever the server says it is until it is mined [4].

What to do now

  • Upgrade to 4.8.3 from electrum.org, where builds for Windows, macOS, Linux and Android are listed with GPG signatures to verify before installing [6].
  • Read every signature, fee bumps included. Electrum's workaround for anyone not yet upgraded is to verify output addresses and amounts each time you sign [2]. On a hardware wallet, that means the device screen, not the computer's.
  • Compare the whole address. The attacker already matches the last four characters [2].
  • Leave a suspicious entry alone. If a payment to an address you don't recognize appears right after you broadcast, the cautious course is not to bump it. Upgrade and check its status through a server you trust. In the first case, the genuine transaction was still intact [2].

The first user did the screen check correctly before broadcasting [2]. The exposure is in the follow-up signature, which feels routine. As our review of this year's three hardware wallet attacks found, the device usually does its job and the failure sits around it. Here the hardware wallet would sign, correctly, a transaction that pays someone else.

Why your own node keeps you out of reach

The advisory states it plainly. Clients that connect to servers they trust, for example ones they run themselves, are not affected [2].

The usual options run on top of a Bitcoin Core node. Electrum Personal Server is a lightweight server for a single user [7]. Fulcrum is a fast server that speaks the same protocol [8], and ElectrumX, the official Python implementation, is listed on Electrum's website next to an install guide [6]. If you already run a node, as covered in our BIP-110 decision tree for node operators and our Bitcoin Core 32.0 checklist, adding one of these is the remaining step.

Running the server is not enough if the wallet still talks to public ones. Electrum Personal Server's documentation recommends launching Electrum with --oneserver --server localhost:50002:s, or setting oneserver=true in the config, so it connects only to yours [7]. One caveat from Electrum's own notes is that Electrum Personal Server cannot be used with Lightning wallets [3].

Privacy improves too. In its default setup, Electrum sends hashes of all its addresses to the server, which can then link them to one owner [4][7]. With your own server, that data stays at home.

More of our self-custody coverage, including the DarkSword iPhone exploit and the CryptoBilis Ledger implant, is collected in the privacy and self-custody section.

The advisory does not name the servers involved or say how much has been lost, and it covers Electrum only [2].

Sources

Source type in brackets.

  1. Electrum (@ElectrumWallet), New release: Electrum 4.8.3, October 24, 2026, 10:06 UTC. Upgrade call for a critical security issue. (Primary, official account on X)
  2. SomberNight (Electrum), Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it, GHSA-6jp4-8v48-cc5v, October 24, 2026. Mechanism, both user reports, fix, workaround and timeline. (Primary, project security advisory)
  3. Electrum, release notes, versions 4.8.3 (October 23, 2026) and 4.0.1 (July 3, 2020). Severity rating and the Electrum Personal Server limitation with Lightning. (Primary, project documentation)
  4. Electrum, Does Electrum trust servers?, FAQ, accessed October 24, 2026. Main server role, SPV and trust in unconfirmed transactions. (Primary, official documentation)
  5. Electrum, commit 90fe308, October 23, 2026. Signature checks on the wallet's own inputs in unconfirmed transactions. (Primary, source code)
  6. Electrum, electrum.org, accessed October 24, 2026. Latest release, downloads, GPG signatures and server links. (Primary, official website)
  7. Chris Belcher, Electrum Personal Server, accessed October 24, 2026. Single-user server, oneserver option and privacy. (Primary, project documentation)
  8. Fulcrum, cculianu/Fulcrum, accessed October 24, 2026. (Primary, project repository)

More in Privacy and self-custody

See all 21 articles in Privacy and self-custody →

Last updated: October 24, 2026