Skip to content
Blockchain Posts

exploit

Electrum 4.8.3 patches rogue-server RBF trap after at least one theft

Electrum's 4.8.3 release fixes GHSA-6jp4-8v48-cc5v, a mempool-signature gap that let hostile servers swap in a fake tx and funnel RBF-bumped funds to the attacker. At least one user lost bitcoin.

by 4 min read
exploitbitcoinelectrumwalletsecurity

Electrum shipped version 4.8.3 on October 24, 2026, fixing a high-severity bug the project tracks as GHSA-6jp4-8v48-cc5v: a malicious Electrum server could substitute a user's just-broadcast transaction for a fake one, then collect the funds once the user tried to speed the payment up with Replace-by-Fee. The advisory, published by maintainer SomberNight, says "some servers are performing this attack in the wild" and credits the second private reporter with disclosing a theft that actually went through.

How the trap works

Electrum is a light client: it trusts the server it connects to for mempool state. The advisory spells out the gap — "the main Electrum server the client connects to is trusted with mempool ('unconfirmed') transactions" — and that in versions below 4.8.3 the client never checked the input signatures on an incoming unconfirmed transaction before adding it to local history.

The chain of events the advisory describes:

  1. The user signs and broadcasts tx1 paying their intended recipient.
  2. A hostile server swallows tx1 instead of relaying it, then returns a conflicting tx2 to the client — same inputs, output flipped to an attacker-controlled address, often with no fee so it looks stuck. "Tx2 has invalid signatures, but this is not checked (due to light client design)."
  3. The attacker picks a recipient address whose last four characters match the real destination — the segment users most often eyeball-verify. The user sees a pending payment to what looks like the right address.
  4. Trying to unstick it, the user triggers a Replace-by-Fee bump. Electrum signs the replacement properly with the user's keys, and the attacker's version — now with valid signatures — propagates and confirms.

The patch

The fix lives in commit 90fe308. Per the advisory: "the client now verifies the signatures of wallet.is_mine inputs for mempool txs." That closes the specific attack path. Full validation of incoming transactions is still out of scope for the light-client model.

- Fixed version:   4.8.3
- Affected:        all versions < 4.8.3
- Advisory:        GHSA-6jp4-8v48-cc5v
- CVE:             none assigned
- Severity:        High (per GitHub advisory)
- Fix commit:      90fe308
- Only vulnerable: clients pointed at an untrusted / hostile server

Disclosure timeline

From the advisory's own log:

  • Oct 11, 2026 — a user running a 2-of-3 multisig with two Trezors reports the behavior privately; no funds lost.
  • Oct 18, 2026 — a second user (credited as Raju-K12) reports losing funds after fee-bumping a substituted transaction.
  • Oct 23, 2026 — Electrum tags 4.8.3 with the fix.
  • Oct 24, 2026 — 4.8.3 binaries ship; GHSA goes public.

Six days from the first confirmed theft to a release. No dollar amount, no stolen address and no victim identity has been disclosed by the project. CoinDesk's writeup adds no further detail on the loss.

Action checklist

  1. Upgrade to 4.8.3 from electrum.org. Every earlier release is affected.
  2. Do not RBF a pending transaction on an unpatched client, even to clear what looks like a stuck payment — the fee bump is the step that signs the attacker's output.
  3. If you run your own Electrum server or point at one you fully trust, you are not exposed by this vector. The attack requires a hostile server in the connection path.
  4. Pre-upgrade, treat the full recipient address as the thing to verify — the "last four characters match" shortcut is specifically what this attack preys on.

Context

Electrum's light-client model has been pulled through this problem before: the 2018–2019 campaign where malicious ElectrumX servers pushed users to fake update downloads via error dialogs is the direct ancestor. The structural lesson has not moved — anything a user sees that originated from an Electrum server has to be treated as hostile until the client has checked it cryptographically — but each wave surfaces another corner where the client did not. The 4.8.3 patch closes one more.

The vector also fits a broader pattern this quarter in Bitcoin tooling: Bitcoin Core's security policy change for LLM-easy bugs pulls in the opposite direction, trying to shrink the window between discovery and patch for the class of bugs whose detection cost has just collapsed. The gap between first private report (Oct 11) and public disclosure (Oct 24) here is the kind of latency that policy is trying to narrow.

Sources:

Related stories