Updated October 28, 2026.
Electrum 4.8.3 fixes a vulnerability that can turn a Bitcoin fee increase into a payment to an attacker. The advisory published on October 24 covers versions before 4.8.3 and describes a malicious server manipulating unconfirmed transaction history before persuading the user to sign the wrong transaction.
The immediate priorities are updating through the official channel and checking destinations and amounts before authorising another signature. This flaw does not establish that every Electrum recovery phrase has been stolen or that Bitcoin accepts transactions with invalid signatures.
Electrum 4.8.3: which installations need attention
The GHSA-6jp4-8v48-cc5v advisory rates the issue as high severity and identifies 4.8.3 as the patched version. Its timeline distinguishes the October 23 software tag from the October 24 publication of binaries and the advisory: those are different stages of the same release.
Anyone using an older installation should first check the running application’s version rather than trusting the name of a desktop shortcut. An old portable executable and an updated installation can coexist on a computer; what matters is which one actually opens the wallet.
This preliminary check also avoids false reassurance. Downloading an update does not prove it has been installed or that the wallet has subsequently been opened with it. Checking the program version does not require sharing a wallet file with anyone.
Why an unconfirmed transaction can be misleading
Electrum is a lightweight client. Its FAQ on server trust explains that the main server provides information about unconfirmed transactions and broadcasts outgoing payments. An entry in the displayed history is therefore not necessarily equivalent to a transaction already verified inside a block.
In the reported scenario, the server withholds the original payment and presents a conflicting transaction with a different destination. That initial replacement lacks the valid signatures required to spend the coins; the dangerous step is the user’s subsequent authorisation while increasing the fee.
The distinction matters: no confirmed blockchain transaction is rewritten. Instead, the context in which a person decides what to sign is manipulated, exploiting a feature normally used to accelerate a slow payment.
Checks before increasing a transaction fee
Replace-by-Fee, or RBF, allows a replacement transaction to offer a higher fee. Our explanation of RBF and CPFP for stuck payments covers ordinary use; this report concerns a particular wallet vulnerability, not evidence that every replacement transaction is unsafe.
| Check | Useful question |
|---|---|
| Version | Am I running the updated program, rather than merely having downloaded it? |
| Recipient | Does the complete address match the agreed destination? |
| Amount | Do the payment amount and revised fee make sense? |
| Change | Can the other outputs be recognised and explained? |
| Signature | Am I authorising the payment I actually intend to make? |
Checking only the last few characters of an address is insufficient. Compare the complete destination against the original payment request obtained through a trusted channel, not a replacement suggested in the same suspicious message.
If the destination has changed or an output cannot be explained, stop signing. Do not raise the fee again to fix a problem that has not yet been identified: paying more in fees cannot make an incorrect destination legitimate.
Getting the update without falling for phishing
The official Electrum website distributes the current release and stresses signature verification. Avoid installers supplied in private messages, sponsored advertisements or pop-ups demanding an urgent wallet recovery.
The official GPG instructions explain how to authenticate a downloaded file. This is separate from signing a Bitcoin transaction: one operation authenticates software, while the other authorises spending.
Never enter a recovery phrase into a website claiming it can check whether the wallet is vulnerable. Our article on protecting a seed phrase explains why support staff should not receive it. Such a request introduces a separate risk rather than forming part of a software update.
What the patch changes, and what if you already signed?
The server’s role also deserves attention after updating. The advisory excludes this scenario for clients connected to a genuinely trusted server, such as their own, but selecting a different public address does not establish that it is trustworthy.
The decision should therefore not be reduced to switching servers and carrying on with old software. For an ordinary user, the practical route remains an official update and verification of payment details.
Running a personal server is an infrastructure choice with its own responsibilities, not an emergency procedure to improvise while completing a transfer. A connection that appears to work does not, by itself, certify the remote service’s honesty.
The fixing commit introduces signature checks for wallet-owned inputs in unconfirmed transactions. It does not turn Electrum into a full node that validates every incoming transaction; the remedy addresses a defined security boundary.
Updating cannot undo an already authorised payment and does not guarantee recovery of coins sent elsewhere. If a payment appears altered, retain its transaction identifier and non-secret details, pause further signing and establish its actual status before taking another action. Avoid recovery services promising certain results in exchange for an advance payment.
Electrum 4.8.3 addresses the documented flaw, but the practical lesson remains straightforward: checking software and checking a payment are separate tasks. No exploit, installation or recovery test was performed for this article. These steps draw on official sources and do not certify the security of an individual device.
