Electrum Wallet Vulnerability Let Malicious Servers Redirect Bitcoin Payments During Fee Bumps
Table of Contents
You might want to know
- How could a wallet’s attempt to speed up a Bitcoin payment lead a user to authorize a payment to an attacker?
- What does Electrum’s security update change, and what should users do if they have not upgraded?
How the Electrum vulnerability worked
A security flaw in Electrum, one of Bitcoin’s oldest software wallets, allowed malicious servers to mislead users who tried to accelerate unconfirmed payments. In at least one reported incident, a user approved a transaction that sent funds to an attacker. Electrum’s developers said that some servers were already exploiting the issue when the vulnerability was disclosed on Saturday.
The developers received two reports in October. One came from a user who said they lost funds after approving what appeared to be a routine increase to a transaction fee. The reports illustrate how a feature intended to help users deal with delayed payments could become a point of risk when wallet software relied on untrusted information from a server.
Electrum works differently from a full Bitcoin node. Rather than independently retrieving all transaction information from the Bitcoin network, it relies on outside servers to look up transaction histories and broadcast payments. Before the fix, Electrum did not verify signatures for certain relevant unconfirmed transactions reported by those servers. As a result, a malicious server could provide the wallet with misleading information about a payment that had not yet been confirmed.
An attacker who controlled or compromised a server used by a wallet could intercept a payment before it reached the Bitcoin network. The attacker could then replace the payment shown in Electrum’s history with a fabricated transaction. That fake transaction appeared to spend the user’s coins to an address controlled by the attacker, but it contained invalid signatures that the vulnerable wallet did not detect.
The fraudulent payment could appear in the wallet as pending. That status mattered because Bitcoin supports replacing an unconfirmed transaction with another version that includes a higher fee. This feature, known as Replace-by-Fee, allows a user to encourage confirmation when an initial payment is taking too long. In the reported attack, choosing the fee-increase option could cause Electrum to take the substituted transaction and sign a valid replacement that sent the funds to the attacker.
The danger arose not simply from an unconfirmed payment, but from the combination of server-supplied transaction data and the user’s later decision to sign a replacement. A user who believed they were increasing the fee on a legitimate payment could instead authorize the attacker’s destination. The wallet’s interface and transaction history therefore played an important role: the substituted payment had to look plausible enough for the user to proceed.
In one reported case, the malicious transaction carried no fee, which could make it appear stuck and encourage the user to try to speed it up. Attackers also created receiving addresses whose last four characters matched those of the legitimate destination. This similarity could make a quick visual comparison less likely to reveal that the destination had changed. Matching a short suffix does not make two addresses equivalent, but it can make a fraudulent substitution harder to notice during a hurried review.
The first report was submitted on Oct. 11. It involved a two-of-three multisignature wallet using two Trezor hardware devices. The user checked the legitimate payment on both devices, then later noticed a different outgoing transaction in Electrum’s history. That user did not report losing funds. The incident nevertheless provided developers with information about how a substituted transaction could appear in a wallet and how the attack might interact with a multisignature setup.
A second user reported the theft on Oct. 18. According to the report, the user raised the fee on a substituted transaction and lost money as a result. Developers have not disclosed how much was stolen or identified the malicious servers involved. The available reports establish that the vulnerability was used in at least one theft, but they do not provide a complete picture of the number of affected users or the total amount of losses.
Electrum responded by releasing version 4.8.3 on Oct. 24. The update added signature checks for unconfirmed transactions that spend coins from the user’s own wallet. By verifying those signatures, the wallet can reject the type of invalid transaction data used in the reported attack instead of displaying it as a trustworthy pending payment.
Earlier versions remain vulnerable to the described attack when connected to malicious servers. The developers advised users to upgrade Electrum and to carefully verify receiving addresses and amounts before signing a payment. Users who connected only to servers they trusted, including servers they operated themselves, were not exposed to this particular attack. That qualification does not remove the value of upgrading: a software update is a direct way to ensure the wallet applies the new validation checks.
The reports also show why reviewing a transaction on a separate hardware device can be valuable, while emphasizing that users still need to inspect the details displayed there. In the first report, the user had checked the legitimate payment on both Trezor devices but later saw a different outgoing transaction in the wallet history. The report did not say that this user lost funds, and it should not be taken as evidence that hardware wallets were generally compromised. Rather, it highlights the importance of checking the precise destination and amount associated with the transaction being signed.
For users reviewing a payment or fee increase, the practical checks are straightforward: confirm the full receiving address, compare the amount against the intended payment, and be cautious if a transaction appears stuck or behaves unexpectedly. Matching only the last few characters of an address is not a sufficient verification method. Users should also confirm that their wallet is connected to a server they trust and install the corrected software version.
The fix was released six days after the first reported theft. That interval marks the period between the initial theft report and the corrective release, but it does not establish when the underlying flaw was first discovered or how long attackers may have exploited it. The developers have not identified the servers or disclosed the amount stolen, so further details about the incident remain unavailable.
Key Insights Table
| Aspect | Description |
|---|---|
| Vulnerability | Before the fix, Electrum did not verify signatures on certain relevant unconfirmed transactions reported by servers. |
| Attack method | A malicious server could substitute a fake pending transaction, then exploit Replace-by-Fee when a user tried to raise its fee. |
| Reported incidents | Developers received two reports in October. One user reported a theft after raising the fee; the other did not report losing funds. |
| Security release | Electrum released version 4.8.3 on Oct. 24, adding signature checks for relevant unconfirmed transactions. |
| Recommended response | Upgrade Electrum, verify full receiving addresses and payment amounts, and use servers that the user trusts. |
Afterwards...
The Electrum incident points to broader questions about how cryptocurrency wallets balance convenience, speed, and independent verification. Wallets that rely on external servers can provide a simpler experience than operating a full node, but their security depends in part on the quality and trustworthiness of information those servers provide. One area for further work is designing wallet software that can validate important transaction details locally, even when it uses outside infrastructure for convenience.
Future development could also focus on making transaction changes easier to recognize. A fee increase should clearly communicate whether the destination address and amount remain the same, and warn users when the underlying transaction differs from what they originally intended. Interfaces could give greater prominence to full addresses and provide clearer ways to compare an original payment with its replacement. Such measures would not replace cryptographic checks, but they could make suspicious changes more visible.
Research into server reliability and decentralized wallet infrastructure is another useful direction. Wallet developers, node operators, and security researchers can explore ways to reduce dependence on a single information source and to detect inconsistent transaction data. Continued review of hardware-wallet signing screens is also important, so those devices can present the transaction details users need to assess rather than merely asking for approval.
For users, the immediate lesson is practical: keep wallet software current, verify the complete destination and amount before signing, and take unusual delays or unexpected transaction-history changes seriously. The longer-term goal is to make safe verification a built-in property of wallet systems, not a step users must perform under pressure.
Last edited at：2026/10/26