Bitcoin wallet bug let rogue servers steal funds when users tried to speed up payments
Attackers replaced legitimate transactions with fake ones, then waited for users to approve higher fees. At least one person lost bitcoin before developers patched the flaw.
A bitcoin wallet security flaw allowed malicious servers to trick users into signing payments to attackers when they tried to speed up transactions, with developers confirming at least one case in which money was stolen.
Electrum, one of Bitcoin's oldest software wallets, disclosed the vulnerability on Saturday, saying some servers were already exploiting it. The developers received two reports in October, including one from a user who lost funds after approving what appeared to be a routine transaction-fee increase.
The attack exploited how Electrum handles bitcoin payments that have not yet been confirmed by the network.
Unlike a full Bitcoin node, Electrum relies on outside servers to retrieve transaction histories and broadcast payments. Before the fix, the wallet trusted those servers to report pending transactions without checking whether their signatures were valid.
An attacker controlling one of those servers could intercept a payment before it reached the Bitcoin network and replace it in the wallet's history with a fake transaction. This replacement spent the user's coins to an address controlled by the attacker, using invalid signatures that Electrum failed to detect.
But the wallet then displayed the fake payment as pending, and the trap came when users tried to speed things up.
Bitcoin allows unconfirmed transactions to be replaced with versions carrying higher fees, a feature called Replace-by-Fee. If a user selected that option, Electrum could take the fraudulent transaction and sign a valid replacement, sending the coins to the attacker.
In one reported case, the malicious transaction carried no fee at all, making it appear stuck. Attackers also generated receiving addresses whose last four characters matched the legitimate destination, making the substitution harder to spot during a quick check.
The first report, submitted Oct. 11, involved a two-of-three multisignature wallet using two Trezor hardware devices. The user had checked the legitimate payment on both devices but later noticed a different outgoing transaction in the wallet's history (that user did not report losing funds).
A second user reported on Oct. 18 that they had raised the fee on a substituted transaction and lost money. Developers have not disclosed the amount stolen or identified the malicious servers.
In response, Electrum released version 4.8.3 on Oct. 24, adding signature checks for unconfirmed transactions spending coins from the user's own wallet. However, earlier versions remain vulnerable to the reported attack when connected to malicious servers.
The developers recommend upgrading and checking receiving addresses and amounts before signing payments. Users connected only to servers they trust, including their own, were not exposed to this attack.
Diversified RWA stablecoins sustain 5-7% yield from real credit as crypto funding compresses to ~4%. GENIUS pushes yield off-chain; TAM grows to $4B in 3 years.
Asanat Analysis — Why it matters
This vulnerability exposes a critical attack vector in wallet UX flows: the fee-acceleration workflow. When users attempt to replace transactions with higher fees (RBF/CPFP), they typically sign new transactions with minimal scrutiny since they assume only the fee changes. Attackers who compromised or impersonated wallet servers exploited this trust by substituting the destination address or amount while keeping the fee bump appearance intact. The user's muscle memory of 'approve the fee bump' became an exploit surface.
The incident underscores why wallet architecture and server trust assumptions matter as much as cryptographic security. A pure client-side wallet eliminates this specific attack; reliance on server-provided transaction data creates risk. This joins a pattern of fee-related exploits (RBF pinning, MEV manipulation, dust attacks) that emerge as transactions become more complex. The patch cycle suggests the flaw existed in production, meaning real user funds were at risk during the window—a reminder that wallet providers remain critical infrastructure with limited insurance mechanisms.