Electrum Advisory: Malicious Server Could Trick Users Into RBF-Signing a Fee Bump to an Attacker's Address

What Happened

Electrum disclosed (GHSA-6jp4-8v48-cc5v) that its design of trusting the connected server with unconfirmed (mempool) transaction data was practically exploited in the wild. According to the advisory, a malicious or compromised server could swallow a client's newly broadcast transaction (tx1), withhold it from propagating over the Bitcoin P2P network, and instead feed the client a conflicting, invalidly-signed replacement transaction (tx2) that redirects the output to an attacker-controlled address. Because Electrum's light-client model does not verify signatures on mempool transactions before this fix, tx2 would display in the wallet's history in place of tx1. If the user then manually bumped the fee (RBF) on what they believed was their original transaction, they would unknowingly sign and broadcast a payment to the attacker.

The advisory states the attacker's substitute address was "grinded" to match the last four characters of the legitimate address in both reported incidents, making the switch harder to notice at a glance. Electrum received two private reports. One user noticed the swapped transaction before acting. The second user (credited as Raju-K12) bumped the fee and lost funds. The fix (commit 90fe30822) is included in version 4.8.3, tagged 2026-10-23, with binaries released and public disclosure on 2026-10-24. It adds signature verification for wallet.is_mine inputs on mempool transactions before they are added to local history. CVSS is listed at 7.5, and the status is noted as having a public PoC.

Why It Matters for Defenders

This affects any Electrum wallet (and Electrum-protocol-compatible clients) that connect to third-party or public Electrum servers rather than a self-hosted trusted node. The advisory explicitly notes self-run servers are not affected. The advisory also states the fix only validates is_mine inputs. Incoming transactions and non-owned inputs are still not fully validated, since Electrum lacks a full consensus or script-interpreting engine. This is a real-money-loss bug already exploited by "some servers" in the wild per the advisory, not a theoretical weakness. It is relevant to anyone supporting users or systems that run Electrum-based wallets, including custodial or semi-custodial services built on it.

What to Watch For / Do Now

• Upgrade Electrum to 4.8.3 or later, and treat Electrum (and any fork or derivative) as in-scope for routine patching given this is an actively-abused design weakness.
• Until upgraded, the advisory's stated workaround applies: manually verify output addresses and amounts (not just trailing or leading characters) before signing any transaction, especially a fee bump.
• If you operate or recommend Electrum server infrastructure, prefer clients configured to connect only to self-hosted or explicitly trusted servers, since the advisory confirms server-side trust is the root exposure.
• For fraud and wallet-monitoring teams: consider flagging and manually reviewing RBF or fee-bump actions where the resulting output address differs from the originally broadcast transaction's output, and watch for transactions that sit unconfirmed with no visibility on the public P2P network for unusually long periods, a pattern described in the reported incidents.
• This is wallet and client-side behavior, not a SIEM-detectable network signature. Any mitigation is primarily a patching and user-verification control rather than a log-based detection.

Developing Intel

This is a same-day disclosure and the full scope of in-the-wild exploitation (how many malicious servers, how many affected users) is not yet established beyond the two reported cases in the advisory. We will track updates as they emerge. Full details: GHSA-6jp4-8v48-cc5v.