Electrum 4.8.3 fixes flaw that let a malicious server disguise theft as a network fee increase

The release notes date the version to 23 October, when the code was tagged in the repository. According to the project's timeline, installers and public disclosure followed the next day. The fix is therefore already available to download, rather than merely promised in a future update.

The transaction on screen was not the payment the user sent

According to Electrum's official security advisory (Opens in a new tab), the server could delay broadcasting the original transaction and instead report a conflicting transaction with the attacker's destination address. The fraudulent transaction's signatures were invalid, but it appeared in the wallet history as unconfirmed.

If the user chose to increase its fee, the wallet signed the replacement transaction. A request that appeared to speed up an existing payment could therefore create a valid payment to the attacker. The project said the attack had already been observed and it had received two user reports, one describing loss of funds after a fee increase. The advisory did not provide an aggregate loss amount.

In both reports, the developers said, the attacker's address had been crafted so its last four characters matched the original address. That is why checking only the ending is insufficient. Even when the familiar part looks correct, the rest of the address may lead elsewhere.

What RBF is, and why increasing a fee requires a signature

RBF, short for Replace-By-Fee, allows an unconfirmed transaction to be replaced by another using the same funds and paying a higher fee. Its familiar use is trying to speed up a long-pending payment. It is not an external addition to a fee already recorded on the blockchain; it creates a replacement transaction that must be signed and sent.

Electrum's documentation describes choosing a fee increase from transaction history, setting the fee, then signing and broadcasting. Starting from an existing wallet entry may make the action look like a small technical adjustment. In practice, the signature validates the transaction details displayed at that moment.

A pending transaction is not yet confirmed. Replacement is intended, among other things, to address delays, but does not guarantee a particular confirmation time. For readers unfamiliar with broadcasting a transaction versus including it in a block, the guide to Bitcoin network fees and confirmations explains exactly what a fee increase seeks to accelerate.

Where the boundary of trust in the server lies

Electrum is a lightweight wallet that uses servers to operate without performing all of a full node's work on the device. The official documentation explains that the main server provides transaction history and broadcasts payments. Confirmed transactions are checked using simplified payment verification, or SPV, while information about unconfirmed transactions relies on the server.

The documentation also makes clear that private keys are not sent to the server. That distinction matters: the attack did not require the server to obtain the key in advance, but exploited how its returned information became the basis for signing. Keeping the key with the user does not remove the need to check what is being signed.

The code fix adds signature verification for transaction inputs spending funds from wallet-owned addresses before accepting the transaction into local history. This targets the exploited path; it does not turn Electrum into a full node independently validating every network detail. According to the advisory, users connected to a trusted server, such as one they operate themselves, are not exposed to this malicious-server scenario.

How to update and check the next payment

Electrum's website warns users to download software only from the official site, electrum.org, and verify the files' GPG signatures. When checked on 25 October 2026, the site displayed version 4.8.3. Reach the site by typing its address yourself or using a familiar bookmark, and select the file matching your operating system.

Signature verification checks the relationship between the downloaded file and the key used to sign it. The official instructions also require identifying the signer's public key and checking its fingerprint against an independent source. A plausible filename is insufficient, and downloading again does not replace verification. Perform the check with each new release download.

Before signing a payment, including a fee increase, check the full destination address, amount and network fee. Compare the destination with the original details received from the recipient, not just the entry the wallet now displays. If using a hardware wallet, also check the transaction details on the device's screen before approval. The guide to wallets and custody explains how software's role differs from the signing device's role.

If the destination or amount does not match, stop signing and investigate the discrepancy before trying again. There is no need to disclose a seed phrase to someone offering to help verify an installation or read a transaction. For an unexpected approach offering a fix, consult the warning signs of crypto scams. The update closes the disclosed vulnerability; checking signing details remains part of everyday wallet use.