Skip to main content
When the Server Lies: Electrum's Fee-Bump Attack
Security
Security
4 min read16 views

When the Server Lies: Electrum's Fee-Bump Attack

Floriano Righetti
Floriano Righetti

On 24 October 2026, the developers of Electrum, a long-running open-source Bitcoin software wallet, published a security advisory for a flaw that lets a malicious server trick a user into paying an attacker. The advisory says some servers were already exploiting it. The fix ships in Electrum 4.8.3. We look at what the developers disclosed, what is still unknown, and what the case shows about trust in light clients.

How the attack works#

Electrum is a light client. It does not run a full Bitcoin node. It relies on external servers for transaction history and for broadcasting payments, and it verifies confirmed transactions with Simple Payment Verification. The advisory states that the "main" server a client connects to is trusted with unconfirmed (mempool) transactions, and calls this "documented design."

According to the advisory, the attack runs in steps:

  • The user broadcasts a transaction (tx1). A malicious server "can swallow it" and not pass it on.
  • The server then updates the wallet's history with a conflicting transaction (tx2) that sends the outputs to an attacker address.
  • Tx2 carries invalid signatures, but older clients did not check them. The wallet shows tx2 as unconfirmed and no longer shows tx1.
  • If the user then fee-bumps tx2 with Replace-by-Fee (RBF), the wallet signs a new, valid version with a higher fee, and "hence pay[s] the attacker."

Two details from the user reports make the trap harder to spot. Both reporters said the attacker's address was ground to match the last four characters of the legitimate address. In one case, the server built tx2 with a zero fee, which the developers believe was meant to make the payment look stuck and invite a fee bump.

What is confirmed#

The advisory, published on GitHub by SomberNight, rates the issue High and lists all versions before 4.8.3 as affected. Its timeline:

  • 11 October: a first user privately reports that their wallet history showed a different transaction from the one they broadcast. The fee-bump vector was not yet understood.
  • 18 October: a second user, credited as Raju-K12, reports losing money after a fee bump.
  • 23 October: version 4.8.3 is tagged with the fix.
  • 24 October: binaries are released and the issue is disclosed publicly.

The fix (commit 90fe308) makes the client verify signatures on inputs the wallet owns before adding unconfirmed transactions to its history. CoinDesk, reporting on 26 October, describes the same mechanism and timeline and reports at least one confirmed theft.

What is not known#

Neither the advisory nor CoinDesk gives the amount stolen. The malicious servers have not been publicly identified, and the number of affected users beyond the two reports is not stated. The developers also note a limit of the fix: only transactions spending the wallet's own coins are validated, so incoming unconfirmed transactions are still not checked. Doing more would require a full script interpreter and recursive checks of unconfirmed parents.

What users are told to do#

The advisory recommends upgrading to 4.8.3. Until then, users should check the output addresses and amounts of every transaction they sign, fee bumps included. Clients that connect only to servers they trust, such as their own, are not affected.

Why we are covering it#

This is not a broken key, a weak seed or a protocol bug. It is a gap between what a wallet shows and what a user signs, opened by a component the client partly trusted. Fee bumping feels routine, and attackers relied on that. In our view, the practical lesson is old but worth repeating: verify the full address and amount at the moment of signing, not only the first or last characters, and know which parts of your setup you are trusting. We will follow up if the developers publish loss figures or identify the servers involved.

Sources#

Share this article

Related Articles

Cysic Bridge Exploit: What the 10M CYS Mint Shows

SecurityOct 19, 20265 min

Cysic Bridge Exploit: What the 10M CYS Mint Shows

On 17 October an attacker minted 10M CYS through Cysic's bridge. What is verified, what is still unknown, and what it shows about bridge trust boundaries.

Read article