Electrum Patches Replace-By-Fee Vulnerability After Rogue Servers Steal Bitcoin

Bitcoin wallet software Electrum released version 4.8.3 following reports that rogue servers exploited mempool handling to trick users into redirecting transactions, according to a GitHub security advisory published on Oct. 24 ¹. The update addresses an architectural blind spot where light clients inherently trust connected servers for unconfirmed transaction data ¹. At the time of writing, $BTC traded around $80,098.

The vulnerability stems from how the Electrum client handles mempool updates ¹. When an end user broadcast an initial transaction, an adversary operating an untrusted server could withhold it from the peer-to-peer network and feed the wallet an invalid replacement transaction containing the attacker's payout address ¹. Because Electrum operates as a lightweight client without a local script interpreter, it displayed the server's fabricated unconfirmed transaction in the wallet interface without verifying signatures ¹. If the user subsequently initiated a manual replace-by-fee (RBF) fee bump, the wallet generated valid signatures for the adversary's outputs, routing the balance directly to the attacker ¹.

Exploitation in the Wild and Deployment Fix

Electrum received two separate reports from affected users indicating the vector was being exploited in the wild ¹. The initial disclosure arrived on Oct. 11, though developers only identified the RBF attack vector after a second user reported financial losses on Oct. 18 ¹. Both users noted that the malicious servers generated vanity addresses matching the final four characters of the legitimate destination, while one server created the spoofed transaction with a zero fee to incentivize a manual fee bump ¹.

Electrum tagged the patch on Oct. 23 and published binaries the following day ¹. Version 4.8.3 enforces signature validation for any mempool transactions that spend outputs owned by the local wallet ¹. Maintainers cautioned that incoming transactions remain unverified prior to block confirmation, as full validation would require recursively evaluating unconfirmed parent transactions without a full consensus engine ¹. Users running their own nodes or connecting exclusively to trusted backend servers were not impacted by the issue ¹.