Electrum 4.8.3 Patches Bitcoin (BTC) Wallet Flaw That Let Malicious Servers Swap Transactions

4.8.3 Closes the Server-Side Gap

Electrum released version 4.8.3 on Saturday, Oct. 24, and told users to upgrade immediately after its developers confirmed that malicious wallet servers were exploiting a flaw present in every earlier release of the Bitcoin (BTC) wallet. The vulnerability is documented in the GitHub security advisory GHSA-6jp4-8v48-cc5v, and its mechanics are unusual: a compromised server could quietly swap one of the user's own payments for a transaction paying the attacker, then wait for the owner to approve the theft. This was an active exploit rather than a weakness on paper, which is why the release notice carried an upgrade-now warning. Electrum is a lightweight wallet that leans on external servers for transaction history, fee estimates and payment broadcast. The design keeps the client small, but it hands each server real influence over what the user sees. Electrum verifies confirmed transactions on its own, yet older versions accepted certain unconfirmed transactions without checking their signatures, a distinction rooted in the malleability problem that Segregated Witness was designed to fix. That gap is what the attacker used. A hostile server could intercept a legitimate payment, block its broadcast and substitute a fraudulent transaction that sent the funds to an address under the attacker's control. The substituted transaction carried an invalid signature, yet the wallet displayed it as an ordinary pending payment, leaving nothing on screen to warn the user. Because the exploit lived in wallet software rather than the network's consensus rules, the incident never put the Bitcoin price or the chain's operation at risk; the protocol itself was untouched. The discovery still matters for Bitcoin wallet security at the client layer: users of every earlier version were told to treat pending payments with suspicion until they upgraded.

The trap closed when a user tried to raise the fee on a stuck payment through Replace-By-Fee, the Bitcoin (BTC) mechanism that lets a pending transaction be rebroadcast at a higher fee rate. Instead of bumping the original payment, the victim could unknowingly sign the replacement, authorizing a transfer of their own coins to the attacker. The deception went further: the attacker generated a receiving address whose final four characters matched the target address exactly, so a quick side-by-side comparison looked clean. One fraudulent transaction in the reports was even set at a zero fee, apparently to bait the victim into adjusting the fee and completing the theft that way. Developers received two private reports. On Oct. 11, user dannydeezy reported a transaction replacement, though the fee-raising mechanism behind it was not fully understood at the time. On Oct. 18, user Raju-K12 reported losing funds after approving a fee increase, and that second report showed the attack working in practice, not only in theory. The fix went in through commit 90fe308, which requires Electrum to verify the signature of any unconfirmed transaction spending the wallet's coins. A fraudulent transaction with an invalid signature is now rejected before it enters the wallet's local transaction history. Users on versions before 4.8.3 should download updates only from electrum.org and verify the cryptographic signatures. Until they upgrade, the developers advise checking every recipient address and amount before signing, including during fee adjustments. Users who connect only to trusted, self-hosted Electrum servers were never exposed to this server-based attack. The episode leaves a paradox on record: a wallet built to protect private keys could still be steered into requesting a perfectly valid signature for a payment its owner never intended.

Server Trust After the Patch

The control Electrum added is narrow and telling: every unconfirmed transaction that spends the wallet's coins must now carry a verified signature before the client stores it. The entire attack chain ran on a trust relationship most light-client users never see, since the client outsources history and broadcast to servers it does not control. In that respect the failure is a cousin of the replay attack, where a user signs a payment they never meant to authorize. The practical lesson lands on server choice and self-custody. Users on self-hosted servers were untouched, a fact that will feed the Bitcoin maximalism argument for verifying rather than trusting, and it will push some larger holders toward hardware options such as the Tangem Mobile Wallet. For everyone else, the four-character address check and the 4.8.3 signature rule are the two habits that close the gap.