Electrum 4.8.3 Patches Actively Exploited RBF Fee-Bump Theft Flaw

Malicious Electrum servers were already stealing funds by silently swapping users' pending Bitcoin transactions before a patch shipped October 24.

Key takeaways

• Electrum released version 4.8.3 on October 24 to patch a confirmed, active exploit (GHSA-6jp4-8v48-cc5v) that let rogue servers replace a user's pending Bitcoin payment with a fraudulent one redirecting funds to an attacker.
• No keys were stolen and no cryptography was broken. The attack lived entirely in the application layer, weaponizing routine fee-bump behavior (RBF) as the trigger after the wallet blindly trusted an external server's transaction data.
• Users connecting to their own self-hosted Electrum server were not exposed. Everyone else running any version before 4.8.3 connected to a public server should update immediately and verify the GPG signature from electrum.org.

Electrum, the long-running open-source lightweight Bitcoin wallet, released version 4.8.3 on October 24 to close a high-severity vulnerability that was already being used in the wild to steal bitcoin, per the project's GitHub security advisory. The attack required no key compromise and broke no Bitcoin protocol rule. It exploited the wallet's blind trust in an external server for unconfirmed transaction state, then used one of the most routine user actions, speeding up a stuck payment, as the moment of theft.

Electrum (@ElectrumWallet) posted on X on October 24, 2026, urging all users to upgrade immediately. The project's statement was direct: "This release fixes a critical security issue, so we urge all users to upgrade."

How the Attack Worked

The mechanics are worth understanding precisely, because the sophistication is in the misdirection.

A user broadcasts a legitimate outgoing payment through a malicious Electrum server. The server suppresses that transaction, never relaying it to the Bitcoin network. Instead, it injects a counterfeit transaction into the user's local wallet history. The fake transaction reuses all the same inputs as the real one but redirects the outputs to an attacker-controlled address, crafted to match the last four characters of the intended recipient address, in the first reported case, both the legitimate destination and the attacker's address ended in "GyQ3", making a visual spot-check very likely to miss the swap. This detail appears in user1's incident report within the primary advisory.

The fake transaction carries a zero fee. That's intentional. A zero-fee transaction sits unconfirmed indefinitely, which naturally prompts the user to bump the fee via Replace-by-Fee. When the user initiates that fee bump, they are signing the attacker's transaction, not their own. That signature is what broadcasts the theft.

The root cause: prior to 4.8.3, Electrum accepted unconfirmed transactions into local wallet history without verifying the cryptographic signatures on inputs the wallet itself controlled. Confirmed transactions went through SPV verification. Pending transactions trusted the server completely.

The fix in commit 90fe308 now validates signatures on wallet-owned inputs before any unconfirmed transaction touches the history screen. Forged transactions with invalid signatures are rejected before the user ever sees them.

One important scope note: the fix covers outgoing transactions spending the wallet's own coins. Incoming payments from external addresses remain unverified at this layer.

The Trust Failure, Not the Protocol Failure

Bitcoin did exactly what it was supposed to do here. The cryptography held. The consensus rules held. Two user-filed reports confirmed at least one case of stolen funds, though the total BTC amount was not disclosed in the advisory and remains unknown.

The attack category matters more than the scale. Any light client that depends on an external server for mempool state carries a version of this surface. The advisory states that some servers were already carrying out this attack at the time of disclosure. This is the gap between holding your keys and actually controlling what you sign. The keys were safe. The wallet was lying about what it was presenting for signature.

This is the same structural argument that runs through hardware wallet supply-chain compromises: the private key is only one layer. The software or hardware presenting the signing request is another, and if that layer is compromised or deceived, the key's security is irrelevant in the moment that matters.

The fix is real and it ships with this release. But the durable fix is eliminating the trust dependency at the root: run your own Electrum server, or move to a full-node-connected wallet stack like Sparrow pointed at your own node. The falsifiable version of that thesis: if Electrum's team can demonstrate that 4.8.3 and its successors eliminate all meaningful server-trust surfaces for transaction signing, and adoption of self-hosted server configurations rises over the next 12 months, this is a one-patch story. If neither happens, the next malicious-server variant will find the next unchecked input in the same blind spot.

What to Watch

The immediate action is simple: open Electrum, check Help > About, and upgrade to 4.8.3 if the version reads anything lower. Download only from electrum.org and verify the GPG signature before installing. Do not treat the update as optional. The advisory confirms active exploitation was underway at disclosure, meaning servers running the attack were live when the patch dropped.

Longer term, watch whether this incident accelerates any changes to how Electrum handles server selection by default. Users who connect to servers they control were never at risk, and that remains a minority configuration for most Electrum users. That gap is the residual risk.

Sources

• Electrum GitHub Security Advisory GHSA-6jp4-8v48-cc5v
• Electrum 4.8.3 release, electrum.org