Electrum 4.8.3 fixes a flaw that turned the fee-bump button into a bitcoin theft

The Electrum wallet has released version 4.8.3 to close a flaw that let a malicious server hide a payment the user had just sent and show a forged lookalike in its place. When the user then pressed the button to raise the fee, the genuine wallet signed the theft. Electrum developer SomberNight disclosed the problem in a GitHub security advisory published on 24 October 2026 at 12:52 UTC and rated High. Its remarks state that “some servers are performing this attack in the wild”. At least one user lost funds. Neither the advisory nor the coverage so far gives an amount, a number of victims or the names of the servers involved.

Every Electrum wallet version earlier than 4.8.3 is affected. The release was tagged on 23 October, according to the project’s release notes, and the binaries went out together with the public disclosure on 24 October. No CVE number has been assigned.

There is no malware in this story and no fake update, the method behind the large Electrum thefts of 2018 to 2020. The 2026 attack works against the genuine, unmodified wallet. It needs two things: the trust Electrum placed in its server for payments that are not yet in a block, and a user who wants a stuck payment to go through faster.

Electrum took its server’s word on unconfirmed payments

Electrum is a light client. It does not download the bitcoin blockchain. It connects to a server, which tells it which transactions concern the wallet’s addresses. For transactions already included in a block, the wallet checks what it is told against block headers, a method called simplified payment verification (SPV); the advisory notes that mined transactions were already checked this way. Payments still waiting for a block were not.

Unconfirmed transactions sit in the mempool, the waiting room of payments that miners have not yet picked up. For those, Electrum relied on the server’s account. The advisory describes this as a documented part of the design, not a bug that slipped in. The bug was what that trust allowed once it met another feature.

That feature is Replace-by-Fee, or RBF. A payment sent with a fee that is too low can wait for hours. RBF lets the sender broadcast a new version of the same payment with a higher fee, which replaces the old one in miners’ queues. Electrum offers it as a fee bump on any pending outgoing payment. Our guide on how crypto transactions move from wallet to block explains fees and the mempool in more detail.

How the swap works, step by step

The advisory’s own title sums up the scheme: “Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it”. Laid out in order, using the mechanism the advisory describes:

1. The user sends bitcoin from Electrum. The wallet signs the payment and broadcasts it.
2. A malicious server swallows that real payment: it never relays it to the bitcoin network and stops reporting it to the wallet.
3. The server feeds the wallet a different transaction that spends the same coins but pays the attacker. This forged transaction is invalid, because the attacker cannot produce the user’s signatures.
4. Electrum before 4.8.3 never checked the signatures of unconfirmed transactions. It showed the forged payment in the history as an ordinary pending transaction and hid the real one.
5. The user sees what looks like a payment stuck in the queue and asks the wallet to increase the fee.
6. To build the fee bump, the wallet starts from the forged transaction and signs a new version with a higher fee. That version carries real signatures, pays the attacker and is valid on the network.

Everything rests on the last step. The forged transaction on its own moves nothing, since any bitcoin node would reject it. It is the user’s signature on the fee bump that turns the attacker’s draft into a payment the network accepts.

From the user’s side, nothing looks broken. The wallet is the real Electrum, downloaded from the real site. The history shows one outgoing payment, roughly the expected amount, still pending. Pressing the fee button is the routine fix for that situation.

The advisory publishes the first reporter’s incident notes, and they show how convincing the swap looked. The wallet was a 2-of-3 multisig secured by two Trezor hardware wallets, spending 31 inputs to a single output. The user checked the output on both Trezors and broadcast. The history then showed the full amount, unconfirmed, going to an unknown address. The fake reused the same inputs and the same signature data as the real payment, but none of its 62 signatures matched it. It paid nearly everything to the lookalike address, sent a small amount back to one of the wallet’s own addresses and left a fee close to zero. The real payment never reached the mempool, and this user did not bump the fee.

A zero fee and an address with the right ending

The forged transactions were built to be bumped. In the second report, the one with a loss, the server built the fake with a zero fee, “presumably in hope of the user bumping its fee”, the advisory says. A payment with no fee does not confirm, which gives a user watching the history a good reason to act.

They were also built to survive a quick look. Both reporters said the attacker’s address had been ground, generated by trial and error, until its last four characters matched the address they meant to pay, according to the advisory. In the first case both ended in GyQ3. A user who checks only the ending sees a match. Our guide to crypto address formats and the mistakes to avoid explains why the whole string matters.

From a first private report on 11 October to the fix on 24 October

Two people reported the problem privately in October, a week apart, and the second one had already lost money, the advisory shows.

Both reports were private, and the advisory is the only public record of them. The 18 October report is the earliest loss on record. The advisory does not say when the hostile servers started, how many there were, or whether the two reporters had reached them through Electrum’s public server list.

What 4.8.3 changes: signatures checked before a pending payment is shown

The fix sits in commit 90fe308, the merge of a branch named verify_sigs, written by SomberNight. It touches seven files, with 446 lines added and 13 removed.

For transactions still in the mempool, Electrum now verifies the ECDSA signatures on every input that belongs to the wallet before it adds the transaction to the history. The check handles multisig wallets, where the order of signatures matters, and both older scriptSig and SegWit witness data. A transaction that fails raises an InvalidTxSignature error and is removed.

The result is narrow but it closes the hole. A hostile server can still hide a payment. It can no longer invent one that spends the user’s coins, because the wallet will spot that the signatures are missing or wrong, and so there is no forged template left for a fee bump to sign.

SomberNight’s write-up is open about what the check does not cover. Only inputs paid from the wallet’s own addresses are verified, so incoming payments are not validated this way. Covering those would mean checking unconfirmed parent transactions one by one back to a mined one, and the client has no full script interpreter to do it, the advisory says. In the code, the watchtower plugin, which holds no keys, skips the verification. A pending payment to the wallet is still, until it confirms, only what the server reports.

Every Electrum release of 2026 is labelled a security update

The release notes list 4.8.3 as a security update, with fixes for reports from four people, including the two behind the fee-bump case. It also adds mempool.space as an exchange-rate provider, ships the DNSSEC root key known as KSK-2024, introduces a dscancel command for cancelling a payment by double-spending it, and adds checks on incoming Lightning HTLCs. One change reaches back to 2018: the graphical interfaces now disable rich-text rendering by default. It is not an isolated patch. The three 4.8 releases before it carry the same label, and so do 4.7.0, 4.7.1 and 4.7.2, published between 22 January and 1 April.

Someone who installed 4.8.0 in July and stopped there is three security releases behind.

Is Electrum wallet safe to use now?

With 4.8.3, the forged-payment route described in the advisory is closed for payments the user sends. Older versions stay exposed whenever they talk to a server the user does not control. The practical steps come from the advisory and from Electrum’s own download page:

• Update to Electrum 4.8.3, downloaded only from electrum.org. The download page says to use no other source, provides signatures, and says the binaries are reproducible and signed by several builders. Check the GPG signature before installing.
• Ignore anyone who offers help by private message. The same page says Electrum does not provide private user support and that such helpers are most likely impostors.
• Until the update is done, read the full destination address and the amount before signing any transaction, a fee bump or a cancellation included. The last four characters are not enough; that is exactly what the attackers matched.
• Be wary of a pending payment that shows a zero fee, or one that seems to invite a fee increase. Compare its address with the one you meant to pay before touching it.
• Connect Electrum to your own server or to one you trust. The advisory says such clients are not exposed.

A hardware wallet does not remove the need to look. A fee bump of the forged payment still has to be signed on the device, which displays the destination; the first reporter’s case shows the lookalike would share its ending with the real address. With a wallet on your own computer, those checks fall on you, the usual trade-off of self-custody.

Who was not exposed: wallets on trusted servers

The advisory names one group out of reach: wallets connected to servers their owners trust, such as a server they run themselves. The attack needs a hostile server on the other end of the connection.

What the advisory does not say

This is a security story, not yet a loss story. The known facts stop at one confirmed victim, a GitHub handle, and an unspecified sum. No total has been published by the advisory or by Bitcoin.com News, The Cryptonomist or TokenPost.

No attacker address, victim address, transaction ID or server name has been made public either. Without them, nobody outside the case can trace the stolen coins on a block explorer, and any loss figure would be a guess. The open questions are the amount taken, the number of victims, the identity and number of the rogue servers, whether the reporters used public servers, and the date the attacks began.

Hostile Electrum servers, 2018 to 2020: the fake-update thefts

Rogue servers have targeted Electrum users before, with a different weapon. From late December 2018, attackers ran many malicious servers whose error messages, displayed as formatted text by Electrum versions before 3.3.3, told users to install an urgent update. The link led to fake GitHub pages and a trojan in place of the wallet.

Decrypt recalled that 202 BTC, about $2.3 million at the time, was reported stolen in the first attacks in December 2018. By 16 April 2019, Malwarebytes Labs counted more than 771 BTC stolen in the campaign, about $4 million then, and named the malware variants OSX.ElectrumStealer and Electrum.Stealer.

In March and April 2019, Electrum’s developers used a denial-of-service flaw in old clients to force versions earlier than 3.3 off public servers, so that they could not receive the fake messages. The attackers answered with a botnet that flooded legitimate servers to push old clients towards rogue ones. The Hacker News reported on 30 April 2019 that the botnet, named ElectrumDoSMiner, ran on more than 152,000 infected machines according to Malwarebytes, that the thefts had reached $4.6 million and that users were told to update to 3.3.4.

The campaign came back in 2020. In late August, a user claimed on GitHub to have lost 1,400 BTC; another claimed 36.5 BTC the next day. ZDNet then reported more than $25 million stolen, and about 1,980 BTC, roughly $22.9 million, sat in wallets linked to the attackers, according to Decrypt on 12 October 2020. Electrum developer Thomas Voegtlin told the publication: “There is a police investigation going on in Germany and in the UK.”

Dollar amounts are those reported at the time, not converted to today’s bitcoin price.

Same hostile server, a different trick

The two episodes share a starting point: a server that lies to the wallet. In 2018 to 2020 the lie was a message, and the theft needed the victim to replace Electrum with malware. In 2026 the lie is a transaction, and the genuine wallet signs the theft itself. There is no file to download, so there is nothing for an antivirus to catch. The only defence on an old version is the user’s own reading of the address before signing.

As our guide on where crypto hacks really happen explains, the chain itself is rarely the weak point; wallets and the people using them are. The same week, Bitcoin Core changed how it discloses bugs, dropping its year-long embargo for flaws an AI can find with one prompt.

As of 25 October, the advisory lists no server names and no transaction IDs. If the developers or the two reporters publish them, the size of the theft can finally be measured on chain.