Electrum 4.8.3. This release fixes a critical security issue

[flatfly]

https://x.com/ElectrumWallet/status/2113935057656369564

Quoting the tweet:

New release: Electrum 4.8.3. This release fixes a critical security issue, so we urge all users to upgrade. A description of the vulnerability will be published later today. (note: Windows Defender may show a warning about ZXing.dll, ignore that, it is a false positive)

[Upgrade00]

The false positive bit is throwing me off. I will not be bypassing a windows warning until I am sure what exactly is the reason it was flagged. I consider there is more risk updating with no more information than sticking to the version I am currently on.

What does other users recommend?

[flatfly]

Advisory has just been published on github:

https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v

[satscraper]

https://x.com/ElectrumWallet/status/2113935057656369564

Quoting the tweet:

New release: Electrum 4.8.3. This release fixes a critical security issue, so we urge all users to upgrade. A description of the vulnerability will be published later today. (note: Windows Defender may show a warning about ZXing.dll, ignore that, it is a false positive)

Forum already has the relevant, more informative post that was published 2hrs before yours. Why duplicate it by creating new thread?

[hosemary]

Forum already has the relevant, more informative post that was published 2hrs before yours. Why duplicate it by creating new thread?

I appreciate you warning users about the security issue in your thread. Thanks for that, but I don't really see any problem with flatfly creating this topic.
This was an urgent announcement, and I think it deserved a separate topic to get more visibility.

[Karl_3000]

Thanks for this information. I will update my wallet to 4.8.3 just right now.

Forum already has the relevant, more informative post that was published 2hrs before yours. Why duplicate it by creating new thread?

I think it is good to have a new thread for it. I was not following that you thread because I have noticed Cygan has always post new threads for Electrum updates which is one of the reasons I have been following the Electrum board. If not for this thread, I would not have seen this important update.

If Electrum has a board, I think there can always be a new topic for new updates.

[Faisal2202]

The false positive bit is throwing me off. I will not be bypassing a windows warning until I am sure what exactly is the reason it was flagged. I consider there is more risk updating with no more information than sticking to the version I am currently on.

What does other users recommend?

I have not updated anything yet. I am waiting, as this update has been changed everywhere on their GitHub too, the sig is correct too, and everything looks so far so good, but I don't know why it feels a little off, as I read a few comments under that tweet and they also had the same thoughts (they can be made to make our doubt solid). Well, I checked everywhere, and so far, there are no signs of their Twitter account being hacked or anything, and the latest update seems fine too, as Satscraper said, so everything seems fine so far! Can't be sure, though.

This was an urgent announcement, and I think it deserved a separate topic to get more visibility.

I agree because otherwise I would not have known this. As I have only put this board on the tracker not that topic.

[ghost43]

The twitter account was not hacked. but even if it was it would not matter much.

The binaries are reproducible and 5 different people built and signed them. The same 5 people that signed the last release and the release before that, etc. There is a tag on GitHub. There is a signed version announcement on the website that the client verifies when it does the update check. The IRC channel topic was updated to say there is a new release.

But if you care about Windows Defender that much, even that false positive should be gone now as Microsoft sent an automated reply to our report and claimed they removed the false positive detection from their database.

Still, you can wait a bit before updating, just read the disclosure then and try to understand it.

[Italian Panic]

It appears that no particular incidents have occurred, and it seems the bug was discovered to the external service owned by Electrum.

The same issue has also been found in Cake Wallet, which has also released an update today.

Essentially, Electrum does not normally download blocks but uses its own external server to manage the mempool. It has been discovered that a malicious server could intercept a users transaction with RBF (where fees are manually increased for various reasons) and insert a second transaction using the first users input but with the output altered to benefit the attacker. In other words a man in the middle.

At this point, the tx has valid signatures because they are not verified by the client (Electrum). If the user manually increases the fees, a sort of switch occurs, triggering the bug: the tx that is validated is the tx of attacker, with funds transferred in their favour, whilst the original transaction disappears.

So, update Electrum and Cake Wallet.

Don't make tx until the update.

[satscraper]

I have not updated anything yet. I am waiting, as this update has been changed everywhere on their GitHub too, the sig is correct too, and everything looks so far so good, but I don't know why it feels a little off, as I read a few comments under that tweet and they also had the same thoughts (they can be made to make our doubt solid). Well, I checked everywhere, and so far, there are no signs of their Twitter account being hacked or anything, and the latest update seems fine too, as Satscraper said, so everything seems fine so far! Can't be sure, though.

I respect your decision to wait a while before updating. ^{I sometimes do the same.} However, I would refer again ^{(as I did in my post you mentioned)} to release notes  “A malicious server can replace a just-broadcast transaction and try to trick the user into RBF-ing it.” The current update fixes this and several others vulnerable glitches. That said, sure, you’re free to make your own choice.

[Wind_FURY]

It appears that no particular incidents have occurred, and it seems the bug was discovered to the external service owned by Electrum.

The same issue has also been found in Cake Wallet, which has also released an update today.

Essentially, Electrum does not normally download blocks but uses its own external server to manage the mempool. It has been discovered that a malicious server could intercept a users transaction with RBF (where fees are manually increased for various reasons) and insert a second transaction using the first users input but with the output altered to benefit the attacker. In other words a man in the middle.

At this point, the tx has valid signatures because they are not verified by the client (Electrum). If the user manually increases the fees, a sort of switch occurs, triggering the bug: the tx that is validated is the tx of attacker, with funds transferred in their favour, whilst the original transaction disappears.

So, update Electrum and Cake Wallet.

Don't make tx until the update.

How did all these vulnerabilities get discovered one after another? Is that because nefarious entities have currently started to use Artificial Intelligence? Because if it could help increase coding output per programmer, then it could probably help those people who hunt bugs, no?

[NotATether]

Damn, the same type of bug as Cake Wallet!

Fortunately, I always use my own server electrum.bitmixlist.org, and if you had your server hardcoded to that one, you are also safe since I run stock Electrs.

Although most people should really be checking the entire address before signing anything.

What does other users recommend?

I recommend uninstalling Windows and putting your Electrum wallet on Linux.

How did all these vulnerabilities get discovered one after another? Is that because nefarious entities have currently started to use Artificial Intelligence? Because if it could help increase coding output per programmer, then it could probably help those people who hunt bugs, no?

Hackers are using swarms of local DeepSeek 4.1 Flash agents to scan and hack info everyone's servers.

Sandboxing largely prevents this.

[DireWolfM14]

~

Can you give us more detail about the malicious servers?  Are they operated by malicious actors, or were they hacked?

Hackers are using swarms of local DeepSeek 4.1 Flash agents to scan and hack info everyone's servers.

How does deepseek find vulnerabilities?  I checked my servers (one publicly available and one private), and neither have any suspicious activities.  Although, the public one is only seeing moderate use, so I doubt it's a target.  The private one is only accessible by vpn.  Both are locked down pretty tight with nftables' IP specific rules and public key authentication for ssh.

Is there anything else I should be doing to harden my setup?

[hosemary]

Can you give us more detail about the malicious servers?  Are they operated by malicious actors, or were they hacked?

The server could refuse to broadcast the user's transaction and update the transaction history with another (invalid) transaction instead of the one the user actually made.
This attack could be carried out by anyone who controlled the server the user was connected to when broadcasting the transaction.

I checked my servers (one publicly available and one private), and neither have any suspicious activities.  

It's normal.
Note that the issue wasn't that hackers could attack servers. It was that servers could attack users.

[NotATether]

How does deepseek find vulnerabilities?  I checked my servers (one publicly available and one private), and neither have any suspicious activities.  Although, the public one is only seeing moderate use, so I doubt it's a target.  The private one is only accessible by vpn.  Both are locked down pretty tight with nftables' IP specific rules and public key authentication for ssh.

The same way Claude, ChatGPT, Grok etc find them, they search the internet for data , and they write code that implements it. Normally, such code output would be flagged as dangerous by the model provider before the response is returned, but since an open model runs locally, there is no one to flag it.

Is there anything else I should be doing to harden my setup?

Use a sandbox like SELinux or AppArmor. That way if some wild vulnerability is discovered overnight and your software gets infected, it won't be able to phone home or spread to other parts of the server.

Pro tip - have AI write the sandbox rules so that you don't have to spend a week learning programming and sysadmin

[coupable]

I think this is a highly important news for those who have been complaining about duplicated topics, given how popular the Electrum wallet is. I think it deserves a dedicated thread on the Electrum child board.
I have already read the latest news from my local board in a dedicated thread created by the moderator. I think that another topic in the Bigenners & Help board is equally important.

It appears that no particular incidents have occurred, and it seems the bug was discovered to the external service owned by Electrum.

I read that there have been 2 users who have complained to Electrum that they have lost money after using the RBF feature. [1]

[1] https://www.kucoin.com/news/flash/electrum-patches-high-severity-bug-after-attackers-steal-btc-by-hijacking-pending-transactions