# Electrum: Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it

Malicious Electrum server swallows a broadcast tx and substitutes an unsigned conflicting mempool tx paying the attacker; user RBF-bumping it signs away funds.

- Payout: Research
- Severity: critical
- Program: Electrum
- Found by (vendor credit): Raju-K12
- Found by: Raju-K12
- Disclosed: 2026-10-28
- CVE: CVE-2026-117601
- Write-up quality: 8/10
- Original: https://github.com/advisories/GHSA-6jp4-8v48-cc5v
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v
- Tags: area:os domain:desktop impact:funds-loss kind:research platform:ghsa sev:critical tech:payment technique:chained vuln:business-logic vuln:crypto

**Target:** Electrum light client / Electrum server mempool history feed
**Root cause:** Light client trusts the server's mempool transactions without verifying input signatures, so a conflicting tx with attacker outputs is accepted into wallet history and later re-signed on fee bump.
**Steps:**
1. Client broadcasts tx1 to its main Electrum server; malicious server swallows it and does not propagate to bitcoin p2p.
2. Server updates client history with conflicting tx2 replacing outputs with attacker address (grinded to match last four chars of legit address); tx2 signatures are invalid but unchecked.
3. Wallet displays tx2 as unconfirmed; tx1 absent.
4. User manually RBF fee-bumps tx2; client signs it with higher fee, paying attacker.
**How found:** User1 noticed wallet history showed a different tx after broadcasting and that tx1 never propagated over p2p; both victims noticed the attacker output address was ground to match the last four characters of the legitimate address.
**Exploitation:** Server withholds the user's real broadcast, injects a zero-fee conflicting tx2 with attacker outputs into the client's history, and waits for the user to bump the fee, at which point the client signs tx2 and funds go to the attacker.
**Insight:** Light clients that trust server-supplied mempool data can be tricked into re-signing attacker-crafted transactions via fee-bump flows; check whether RBF/bump paths re-validate outputs against the original tx rather than trusting displayed history.