#electrum修复4.8.3前版本高危漏洞
All 62 signatures verified, but the receiving address wasn’t yours
📣 盘面异动群里喊
On October 24, veteran Bitcoin wallet Electrum released a security update, version 4.8.3. The official announcement rated the vulnerability High and said it affected all versions before 4.8.3. No CVE number was assigned, but the announcement included a stark warning: servers had already done this in the wild 🦖
You probably use a lightweight wallet. It doesn’t download the entire blockchain; instead, it trusts a server to tell you your balance and transactions. The official documentation says this is a deliberate trade-off. The problem is that it’s been weaponized ⚠️
An attacker controls the server you’re connected to. You click Broadcast in your wallet, but the server swallows the real transaction—it never makes it into the mempool. Then the server feeds your wallet a fake transaction. It has exactly the same inputs, version, and lock time as the transaction you just made. The signature scripts for all 31 inputs are byte-for-byte identical. The only difference is that the output address has been changed to the attacker’s, and this fake address has been calculated repeatedly just to make its last four characters exactly match those of the address you actually intended to send to.
All the signatures on the fake transaction are invalid, but lightweight wallets don’t verify scripts, so they can’t tell. Your real transaction disappears from your history, leaving only an unconfirmed fake one. The amount looks exactly like what you meant to pay. The scammer also sets the fee close to zero, waiting for you to notice the transfer is stuck and manually click to bump the fee.
When you bump the fee, your wallet signs that fake transaction. You’ve just signed your coins over to the attacker yourself 💥
The announcement describes two real cases. On October 11, the first user privately reported the issue. They had an old-style 2-of-3 multisig with two Trezor hardware wallets, 31 inputs, and 1 output. They checked the address on both hardware wallet screens before broadcasting. But then an unconfirmed transaction to an unfamiliar address appeared in their history. On October 18, a second user reported that they had bumped the fee—and the money was gone. It took just 12 days from the first report to labeling the issue in 4.8.3, and 13 days to release the binary.
To me, the key point isn’t that Electrum wrote faulty code. It’s a boundary everyone takes for granted: the server you trust is effectively your ledger. Whatever it shows you, you assume happened. This incident simply turned that assumption into an attack path that can be carried out.
Even after the fix, version 4.8.3 only verifies inputs belonging to your own wallet. Transactions sent to you by others still aren’t verified, because lightweight clients don’t have a full consensus engine. The developers themselves acknowledge that covering this would require recursively verifying unconfirmed parent transactions, which would be too costly.
There are three things you can do: upgrade to 4.8.3 immediately; always check the output address and amount before bumping a fee; and, for the long term, run your own server. The official announcement explicitly says that users connected to their own server aren’t affected by this vulnerability.
Do you use a lightweight wallet, or do you run your own node? Let’s discuss in the comments.
Tap the profile picture to watch the livestream.
Every day, I’ll help you follow Bitcoin security developments—not just what’s happening, but also the logic and opportunities behind it 👀🚀
All 62 signatures verified, but the receiving address wasn’t yours
📣 盘面异动群里喊
On October 24, veteran Bitcoin wallet Electrum released a security update, version 4.8.3. The official announcement rated the vulnerability High and said it affected all versions before 4.8.3. No CVE number was assigned, but the announcement included a stark warning: servers had already done this in the wild 🦖
You probably use a lightweight wallet. It doesn’t download the entire blockchain; instead, it trusts a server to tell you your balance and transactions. The official documentation says this is a deliberate trade-off. The problem is that it’s been weaponized ⚠️
An attacker controls the server you’re connected to. You click Broadcast in your wallet, but the server swallows the real transaction—it never makes it into the mempool. Then the server feeds your wallet a fake transaction. It has exactly the same inputs, version, and lock time as the transaction you just made. The signature scripts for all 31 inputs are byte-for-byte identical. The only difference is that the output address has been changed to the attacker’s, and this fake address has been calculated repeatedly just to make its last four characters exactly match those of the address you actually intended to send to.
All the signatures on the fake transaction are invalid, but lightweight wallets don’t verify scripts, so they can’t tell. Your real transaction disappears from your history, leaving only an unconfirmed fake one. The amount looks exactly like what you meant to pay. The scammer also sets the fee close to zero, waiting for you to notice the transfer is stuck and manually click to bump the fee.
When you bump the fee, your wallet signs that fake transaction. You’ve just signed your coins over to the attacker yourself 💥
The announcement describes two real cases. On October 11, the first user privately reported the issue. They had an old-style 2-of-3 multisig with two Trezor hardware wallets, 31 inputs, and 1 output. They checked the address on both hardware wallet screens before broadcasting. But then an unconfirmed transaction to an unfamiliar address appeared in their history. On October 18, a second user reported that they had bumped the fee—and the money was gone. It took just 12 days from the first report to labeling the issue in 4.8.3, and 13 days to release the binary.
To me, the key point isn’t that Electrum wrote faulty code. It’s a boundary everyone takes for granted: the server you trust is effectively your ledger. Whatever it shows you, you assume happened. This incident simply turned that assumption into an attack path that can be carried out.
Even after the fix, version 4.8.3 only verifies inputs belonging to your own wallet. Transactions sent to you by others still aren’t verified, because lightweight clients don’t have a full consensus engine. The developers themselves acknowledge that covering this would require recursively verifying unconfirmed parent transactions, which would be too costly.
There are three things you can do: upgrade to 4.8.3 immediately; always check the output address and amount before bumping a fee; and, for the long term, run your own server. The official announcement explicitly says that users connected to their own server aren’t affected by this vulnerability.
Do you use a lightweight wallet, or do you run your own node? Let’s discuss in the comments.
Tap the profile picture to watch the livestream.
Every day, I’ll help you follow Bitcoin security developments—not just what’s happening, but also the logic and opportunities behind it 👀🚀