Electrum wallet vulnerable before version 4.8.3: what you can do now

Anyone keeping bitcoin in Electrum should check their wallet's version number today. Every release before 4.8.3 carries a flaw through which a malicious server can get you to sign a payment to an attacker. The developers closed it on October 23, 2026 and disclosed it a day later. Their security advisory contains the sentence that separates this case from a theoretical weakness: some servers are already carrying out this attack.

The flaw is rated high in severity and carries no CVE number. What is remarkable is not its technique but its lever: it does not harvest your keys and breaks no encryption. It waits for you to speed up a stuck transaction, one of the most common moves in everyday bitcoin use.

What Electrum 4.8.3 fixes: signatures for your own inputs are checked

Electrum is a lightweight wallet, a so-called light client. The term describes a wallet that keeps no full copy of the Bitcoin blockchain but asks an external server which transactions belong to its addresses. That makes it fast and economical, and it shifts part of the trust onto that server.

That is exactly where the attack came in. Up to version 4.8.3, Electrum took unconfirmed transactions into its local history without checking their signatures. The fix reverses that: before an unconfirmed transaction enters the history, the wallet checks the signatures of those inputs that belong to it. A forgery with an invalid signature is therefore caught before it appears in the history.

The advisory names one limitation itself: inputs that do not belong to your own wallet remain unchecked. Incoming payments from external addresses are therefore still not fully verified. For the attack path described, the new check is sufficient, because that path necessarily reuses your own inputs.

Replace-by-fee: when raising the fee becomes a second signature

Replace-by-fee, or RBF for short, is a procedure with which you replace a still unconfirmed bitcoin transaction with a new one carrying a higher fee. That is standard practice and sensible: anyone who calculated too tightly with a full mempool would otherwise be stuck for hours. How it works in practice is set out in our guide to stuck bitcoin transactions with RBF and CPFP.

The decisive point: raising a fee is technically not a correction of the old transaction but a new one that has to be signed again. In the send dialog, that looks like a formality. You checked the recipient address a moment ago, you only want to add to the fee. If you sign a transaction at this point that an attacker built, you are signing their recipient address along with it.

The attack path: from a suppressed broadcast to a forged history

The security advisory describes five steps. Your wallet sends a transaction, call it tx1, to the server. The server does not relay it but discards it. It then places a second transaction in your history, tx2. That one uses the same inputs as tx1 but sends almost all outputs to an address belonging to the attacker.

The signatures of tx2 are invalid, because the attacker does not hold your keys. Because the old Electrum release did not check them, it displayed tx2 as unconfirmed anyway. Your own tx1 was missing from the history; it had never reached the network. To you, that looked like a payment failing to get through.

In one of the reported cases, the server had built tx2 with a fee of zero. That is not an oversight but part of the bait: a transaction without a fee never moves, and the obvious reaction to that is to reach for the fee increase.

Why the forgery was displayed at all

A full Bitcoin node would have discarded tx2 immediately, because it checks every signature against the blockchain. A lightweight wallet, by design, does not do that for everything it receives. The attack exploited this division of labour without overcoming any cryptographic hurdle. It demanded of the server neither a valid key nor a broken signature, only the certainty that nobody would recalculate.

Two reported cases, one loss: the disclosure timeline

The developers name two independent reports. On October 11, 2026, a user described how, after sending, a different transaction stood in their history while their own never reached the Bitcoin network. The route via the fee increase had not yet been recognized at that point. On October 18, a second user reported a loss after raising the fee on the foreign transaction.

Five days later, on October 23, release 4.8.3 with the fix was tagged. On October 24, the finished binaries and the public disclosure followed. The developers give no figure for the size of the loss, and they name no number of affected users beyond these two reports. Anyone reading otherwise is reading an estimate.

The primary source is the front page of electrum.org, which lists 4.8.3 as the current release, along with the release notes. The technical description is in security advisory GHSA-6jp4-8v48-cc5v.

Addresses ground down to four characters: the deception in the send dialog

Both reports share one detail that explains why a quick visual check was not enough. The attackers had kept generating their recipient address until its last four characters matched those of the real destination address. This procedure is called vanity grinding: you work through key pairs until the corresponding address carries a desired pattern.

Four matching characters at the end are cheap to produce and hit exactly the spot many users look at. Anyone checking a bitcoin address in practice rarely checks every character, but the beginning and the end. That very habit was the target.

Who was not affected: your own server and the role of the hardware wallet

One group stayed out of it. Anyone connecting their Electrum wallet to a self-operated or otherwise trusted server was not exposed to the attack, because without a malicious server the first step is missing. In its default setting, Electrum connects to public servers that anyone can run, and that is the normal case with this wallet.

A hardware wallet helps only to a limited extent here, and it is worth knowing the difference. It protects the private key from the computer, not from a wrong recipient address in the send dialog. If your device displays address and amount on its own screen and you compare them there, it catches the deception. If you rely on the display on the computer, the hardware wallet signs the manipulated transaction just the same. Which devices show address and amount on a screen of their own is set out in our comparison of hardware wallets.

Self-custody in Europe: liability stays with the holder

If you keep your bitcoin yourself, you carry the risk alone. This form of custody does not fall under the European crypto regulation MiCA, which regulates service providers, not private individuals holding their own keys. There is no deposit guarantee, no chargeback and no provider that makes up a shortfall. A signed and confirmed bitcoin transaction is final.

In practice that means: the protection lies in the software you run and in the care you take when signing. The lesson from this case is an uncomfortable one, because it cuts both ways: checking before you sign does not replace up-to-date software, and up-to-date software does not replace the check.

What else is in Electrum 4.8.3: DNSSEC, BOLT11 and descriptors

The release notes for 4.8.3 list the security fix as the only item with a severity rating, but alongside it a series of further changes. Newly added is mempool.space as a source for exchange rates, plus a trust anchor for DNSSEC validation. The exchange rate module has been reworked, and network requests no longer run through the Qt library.

In the area of transactions and key management, the notes name stricter checks when reading descriptors and BIP32 paths, as well as several fixes in signing. For the Lightning function, a stricter check of BOLT11 invoices and a fixed race condition in channel backups are listed. This is therefore a security release with a larger maintenance package, not a pure emergency patch.

Version number and download source: electrum.org and the GPG signature

The running version is shown in Electrum under the menu item with the program information, on the desktop usually under Help. If a number lower than 4.8.3 is shown there, the flaw applies to your installation. For the Android release from Google Play or F-Droid, the respective store page gives the version number.

On obtaining it there is a warning that Electrum itself puts front and centre on its home page: do not download the software from any source other than electrum.org. Forged Electrum packages are a separate, older attack path. The binaries are built reproducibly and signed independently by several people, whose GPG signatures you can check before installing. With a wallet that trusts external servers, that check is the cheapest security gain you can have.

Your seed is untouched by an update; it does not require setting the wallet up again. It should nevertheless be backed up and accessible before any intervention in the installation.

An interim measure without updating: compare the address before every signature

The advisory names an interim measure for this case. Before every signature, check the recipient address and the amount, and do so just as thoroughly for a fee increase as for the first send. Do not take the address by its last characters but in full, or compare it on the screen of a separate device.

You now know a second warning sign: if a transaction you do not recognize appears in the history after sending, or your own is missing, then that is not a display error that can be fixed with a higher fee. In that situation, raising the fee is precisely the wrong move.

Electrum update: without 4.8.3 the server decides what you see

1. Check the version and update. If a number below 4.8.3 is shown in your wallet, get 4.8.3 exclusively from electrum.org and check the GPG signature. Until then, no fee increase on a transaction you did not create yourself. Anyone wanting to switch wallets anyway can review the alternatives in our software wallet comparison.
2. Compare every address in full. The last four characters are no proof; they were reproduced exactly in both cases. If you have a device with a screen of its own, the check runs there, and which devices manage that is shown in our hardware wallet comparison.
3. Review your server connection and the alternatives. Anyone using their own or a trusted server was not affected by this attack. Which wallet software permits which choice of server at all is shown in our software wallet comparison.

(As of October 25, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)