Electrum-Wallet vor Version 4.8.3 anfällig: So schützen Sie sich

Bitcoin holders who use Electrum should check their wallet version immediately. Any release prior to 4.8.3 contains a vulnerability that allows a malicious server to trick users into signing a payment intended for an attacker. The developers patched the flaw on October 23, 2026, and disclosed it publicly the following day. Their security advisory highlights a critical detail separating this from a purely theoretical issue: several servers are already actively executing this attack.

Rated as high severity, the vulnerability does not carry a CVE number. Its effectiveness stems not from sophisticated cryptographic breaking or key theft, but rather from a clever leverage point: it targets users attempting to accelerate a stuck transaction, a routine action in daily Bitcoin operations.

What Electrum 4.8.3 fixes: Verifying signatures for own inputs

Electrum is a lightweight wallet, or light client, meaning it does not maintain a full copy of the Bitcoin blockchain. Instead, it queries a remote server to determine which transactions belong to its addresses. This architecture ensures speed and efficiency while shifting a degree of trust onto that external server.

Demo advertisement

The attack directly exploited this mechanism. Prior to version 4.8.3, Electrum incorporated unconfirmed transactions into the local history without verifying their signatures. The fix reverses this behavior: before an unconfirmed transaction enters the history, the wallet checks the signatures of any inputs belonging to the user’s own wallet. Consequently, a forged transaction bearing an invalid signature is identified and flagged before appearing in the transaction log.

The advisory notes an inherent limitation: inputs belonging to external wallets remain unverified. Incoming payments from unfamiliar addresses are still not entirely validated. However, the new verification is sufficient to thwart this specific attack vector, which inherently repurposes the user’s own inputs.

Replace-by-Fee: When a fee bump acts as a second signature

Replace-by-Fee (RBF) is a standard mechanism that allows users to replace an unconfirmed Bitcoin transaction with a new one featuring a higher fee. This is a practical tool when network congestion leaves transactions stuck for hours.

Crucially, increasing a fee is not a technical correction of the original transaction, but an entirely new transaction that requires a fresh signature. In the sending interface, this appears to be a mere formality—users who have already verified the recipient address simply wish to append a higher fee. However, signing a transaction crafted by an attacker at this stage inadvertently signs over the attacker’s recipient address.

The attack vector: From suppressed broadcast to fabricated history

The security advisory outlines a five-step process. First, the user’s wallet broadcasts a transaction—let’s call it tx1—to the server. Rather than propagating tx1 to the network, the server discards it. Next, the server injects a second transaction, tx2, into the user’s local history. This transaction utilizes the exact same inputs as tx1 but routes nearly all outputs to an address controlled by the attacker.

Because the attacker does not possess the user’s private keys, the signatures on tx2 are invalid. Older Electrum versions failed to check these signatures, displaying tx2 as unconfirmed anyway. Because tx1 was discarded and never reached the network, the user was left with the false impression that their initial payment had stalled.

In one reported incident, the server constructed tx2 with a zero-fee structure. This served as bait: a zero-fee transaction never moves, naturally prompting the user to initiate a fee increase.

Why the forged transaction was displayed

A full Bitcoin node would instantly reject tx2 by validating every signature against the blockchain. By design, light clients do not perform this exhaustive check for incoming data. The attack exploited this division of labor without breaking cryptographic hurdles, requiring the server neither to hold valid keys nor to forge signatures—only to rely on the fact that the client would not recalculate the math.

Two reported cases, one loss: The disclosure timeline

The developers cited two independent reports. On October 11, 2026, a user reported that a different transaction appeared in their history after sending funds, while their own transaction never reached the network; the fee-bumping exploit path had not yet been identified at that time. On October 18, a second user reported financial loss after attempting to increase the fee on the unfamiliar transaction.

Five days later, on October 23, version 4.8.3 containing the patch was tagged, followed by the release of compiled binaries and public disclosure on October 24. The developers have not disclosed the total financial loss or the number of affected users beyond these two reports.

The primary source remains the electrum.org homepage, which lists version 4.8.3 as current alongside its release notes. Technical details are documented in security advisory GHSA-6jp4-8v48-cc5v.

Addresses polished to four characters: Deception in the send dialog

Both reported incidents shared a specific detail explaining why a quick visual check failed. The attackers generated recipient addresses via “vanity grinding”—iteratively producing key pairs until the resulting address matched the final four characters of the legitimate destination.

Matching the last four characters is inexpensive to generate and targets the exact area users tend to inspect. In practice, users rarely verify every character of a Bitcoin address, typically glancing only at the beginning and end. This habit formed the basis of the exploit.

Who remained safe: Self-hosted servers and hardware wallets

Users who connected their Electrum wallet to a self-hosted or otherwise trusted server were immune to the attack, as the exploit relies on a malicious server for its initial step. By default, Electrum connects to public servers operated by third parties, which is standard behavior for the wallet.

Hardware wallets offer limited protection here, and understanding the distinction is vital. A hardware wallet secures private keys against a compromised computer, not against a fraudulent recipient address displayed in the software interface. If a hardware device displays the address and amount on its own screen and the user verifies it there, the deception is thwarted. Relying solely on the computer monitor, however, will result in the hardware wallet blindly signing the manipulated transaction.

Self-custody and liability

Users who hold their own Bitcoin bear the risk entirely. Self-custody falls outside the scope of regulatory frameworks like Europe’s MiCA, which governs intermediaries rather than private keyholders. There is no deposit insurance, no chargeback mechanism, and no provider to absorb losses. A signed and confirmed Bitcoin transaction is final.

Consequently, security relies heavily on running updated software and maintaining strict diligence when signing transactions. The lesson from this incident is twofold: checking transactions before signing does not replace running updated software, and running updated software does not eliminate the need for manual verification.

What else is new in Electrum 4.8.3: DNSSEC, BOLT11, and descriptors

While the security patch is the only feature designated with a severity rating in the 4.8.3 release notes, the update includes several other modifications. Mempool.space has been added as an exchange rate source alongside a trust anchor for DNSSEC validation. The exchange rate module was overhauled, and network requests no longer route through the Qt library.

In the domain of transactions and key management, the notes outline stricter validation when parsing descriptors and BIP32 paths, alongside multiple signing fixes. Lightning network features receive stricter validation of BOLT11 invoices and a fix for a race condition concerning channel backups. Overall, the release functions as a security update bundled with maintenance enhancements rather than a bare emergency patch.

Version numbers and sourcing: electrum.org and GPG signatures

Users can verify their current version via the application information menu within Electrum, typically found under “Help” on desktop. If the listed version is lower than 4.8.3, the installation is vulnerable. For Android users relying on Google Play or F-Droid, the app store page displays the version number.

Electrum emphasizes a strict warning on its homepage: software should be downloaded exclusively from electrum.org. Fake Electrum packages represent an older, separate attack vector. The application binaries are built reproducibly and independently signed by multiple maintainers, allowing users to verify GPG signatures before installation. Performing this check provides an affordable security gain for any wallet trusting external servers.

A software update leaves user seeds untouched and does not require a wallet re-initialization. Nonetheless, verifying that backups are accessible prior to modifying any installation is strongly recommended.

Interim workaround without updating: Address verification before signing

The security advisory outlines an interim workaround for users unable to update immediately. Before authorizing any signature, users must inspect the recipient address and amount just as thoroughly during a fee increase as during an initial send. Verification should encompass the entire address rather than just the final characters, or be confirmed on a separate hardware display.

Additionally, users should heed a key warning sign: if an unfamiliar transaction appears in the history log after sending funds, or if a legitimate transaction vanishes, it is not a visual glitch correctable by a fee bump. Attempting to increase fees under these circumstances is precisely what the exploit aims to provoke.

Electrum update checklist

1. Check version and update. If the wallet displays a version below 4.8.3, download the update exclusively from electrum.org and verify the GPG signature. Refrain from performing fee bumps on unfamiliar transactions until updated.
2. Compare every address fully. Final four characters do not prove authenticity, as attackers can duplicate them. Verification should occur on a hardware device screen where applicable.
3. Verify server connections. Users operating their own or trusted servers were unaffected by this attack vector.

(As of October 25, 2026. This article does not constitute financial advice. Exchange rates and fee models change; verify terms directly with providers before executing transactions.)