Electrum 4.8.3 Patches Bitcoin (BTC) Wallet Flaw That Let Malicious Servers Swap Transactions

Update 10:36 UTC: The document also clarified the disclosure timeline: when the private report arrived on Oct. 11, developers noted that "the bump_fee vector is not realised," and it took Raju-K12's Oct. 18 loss report to expose how the fee-raising trap actually worked.

4.8.3 Closes the Server-Side Gap

Electrum released version 4.8.3 on Saturday, Oct. 24, and told users to upgrade immediately after its developers confirmed that malicious wallet servers were exploiting a flaw present in every earlier release of the Bitcoin (BTC) wallet. The vulnerability is documented in the GitHub security advisory GHSA-6jp4-8v48-cc5v, and its mechanics are unusual: a compromised server could quietly swap one of the user's own payments for a transaction paying the attacker, then wait for the owner to approve the theft. This was an active exploit rather than a weakness on paper, which is why the release notice carried an upgrade-now warning. Electrum is a lightweight wallet that leans on external servers for transaction history, fee estimates and payment broadcast. The design keeps the client small, but it hands each server real influence over what the user sees. Electrum verifies confirmed transactions on its own, yet older versions accepted certain unconfirmed transactions without checking their signatures, a distinction rooted in the malleability problem that Segregated Witness was designed to fix. That gap is what the attacker used. A hostile server could intercept a legitimate payment, block its broadcast and substitute a fraudulent transaction that sent the funds to an address under the attacker's control. The substituted transaction carried an invalid signature, yet the wallet displayed it as an ordinary pending payment, leaving nothing on screen to warn the user. Because the exploit lived in wallet software rather than the network's consensus rules, the incident never put the Bitcoin price or the chain's operation at risk; the protocol itself was untouched. The discovery still matters for Bitcoin wallet security at the client layer: users of every earlier version were told to treat pending payments with suspicion until they upgraded.

The trap closed when a user tried to raise the fee on a stuck payment through Replace-By-Fee, the Bitcoin (BTC) mechanism that lets a pending transaction be rebroadcast at a higher fee rate. Instead of bumping the original payment, the victim could unknowingly sign the replacement, authorizing a transfer of their own coins to the attacker. The deception went further: the attacker generated a receiving address whose final four characters matched the target address exactly, so a quick side-by-side comparison looked clean. One fraudulent transaction in the reports was even set at a zero fee, apparently to bait the victim into adjusting the fee and completing the theft that way. Developers received two private reports. On Oct. 11, user dannydeezy reported a transaction replacement, though the fee-raising mechanism behind it was not fully understood at the time. On Oct. 18, user Raju-K12 reported losing funds after approving a fee increase, and that second report showed the attack working in practice, not only in theory. The fix went in through commit 90fe308, which requires Electrum to verify the signature of any unconfirmed transaction spending the wallet's coins. A fraudulent transaction with an invalid signature is now rejected before it enters the wallet's local transaction history. Users on versions before 4.8.3 should download updates only from electrum.org and verify the cryptographic signatures. Until they upgrade, the developers advise checking every recipient address and amount before signing, including during fee adjustments. Users who connect only to trusted, self-hosted Electrum servers were never exposed to this server-based attack. The episode leaves a paradox on record: a wallet built to protect private keys could still be steered into requesting a perfectly valid signature for a payment its owner never intended.

The advisory's incident reports added technical detail on how closely the fake mirrored the real payment. In the case documented by dannydeezy, a 2-of-3 legacy P2SH multisig setup with two Trezors produced a transaction with 31 inputs and one output; the user checked the output on both hardware devices before broadcasting. The fraudulent copy replicated the real transaction's inputs, version and locktime, carrying byte-identical scriptSigs across all 31 inputs, and sent most of the funds to a lookalike address ending in GyQ3, the same four characters as the legitimate destination, with a small change returned to one of the wallet's own used addresses. All 62 signatures on the fake validated against the real transaction but none against the forged one, and the wallet's history later flipped the entry to "Local." Maintainer SomberNight tagged version 4.8.3 on October 23, with binaries following the next day.

The advisory also drew the line around what the fix does and does not cover. Version 4.8.3 verifies only the signature inputs that spend the wallet's own coins; incoming payments to the wallet are still accepted without verification, because Electrum lacks a full consensus engine and would need to trace every unconfirmed upstream transaction back to a confirmed block, where simplified payment verification already applies. The wallet's documentation states it connects to roughly 10 default servers, with one acting as the main server, and that unconfirmed activity is trusted from that main server by design. The advisory withheld both the identity of the servers that launched the attack and the victim's loss amount, and the first reporter recorded no loss.

The GitHub advisory formally rated the flaw as high severity and confirmed it was exploited in the wild, a classification that puts the incident among the more serious client-level threats recorded for lightweight wallets. The document also clarified the disclosure timeline: when the private report arrived on Oct. 11, developers noted that "the bump_fee vector is not realised," and it took Raju-K12's Oct. 18 loss report to expose how the fee-raising trap actually worked. Both victims told developers the attacker's address ended in the same four characters as their intended destination, and the advisory described the zero-fee forgery as "presumably in hope of the user bumping its fee," a bait that worked in at least one case.

Server Trust After the Patch

The control Electrum added is narrow and telling: every unconfirmed transaction that spends the wallet's coins must now carry a verified signature before the client stores it. The entire attack chain ran on a trust relationship most light-client users never see, since the client outsources history and broadcast to servers it does not control. In that respect the failure is a cousin of the replay attack, where a user signs a payment they never meant to authorize. The practical lesson lands on server choice and self-custody. Users on self-hosted servers were untouched, a fact that will feed the Bitcoin maximalism argument for verifying rather than trusting, and it will push some larger holders toward hardware options such as the Tangem Mobile Wallet. For everyone else, the four-character address check and the 4.8.3 signature rule are the two habits that close the gap.