Four matching characters hid an Electrum payment switch

A familiar address ending can hide a different recipient. In both reports described by Electrum’s maintainers, the attacker’s destination matched the intended recipient’s final four characters .

What fixes Electrum's transaction redirection exploit?

Update affected Electrum installations to version 4.8.3, verify the installer, and review the full destination and amount before signing any payment or fee increase . The maintainers’ advisory describes two reports involving attacker addresses that matched the intended recipient’s final four characters .

Quick Answer: Electrum’s transaction-redirection fix is version 4.8.3; earlier versions are affected . Install a verified fixed release from the official website, pause fee increases on suspicious payments, and check the entire recipient address and amount before signing. Matching address endings do not establish that the recipient is correct.

The version boundary matters: the advisory identifies versions below 4.8.3 as affected, and the official download site listed 4.8.3 as its latest release when checked on October 29, 2026 . This is a dated release check, not a permanent latest-version designation.

The attack turns a routine fee adjustment into a payment switch. Replace-by-Fee is a mechanism for replacing a pending Bitcoin transaction with one offering a higher fee. According to the security advisory, a malicious server suppresses the intended payment and supplies an invalid transaction paying the attacker. Manually increasing that transaction’s fee can cause the affected wallet to sign a valid attacker-directed payment. A pending entry therefore deserves inspection before any attempt to accelerate it.

• Check your installed version. Compare it with the affected-version boundary before initiating another payment or adjusting a pending transaction.
• Pause suspicious fee increases. If a destination, amount, or pending transaction looks unfamiliar, stop before approving a replacement.
• Install a verified fixed release. Navigate directly to the official website and follow its GPG signature-verification instructions. Independently check the signing key’s fingerprint; downloading a signature alone does not verify the installer.
• Reconcile details before signing. Compare the complete destination with the intended recipient’s address, then check the amount. Treat a fee increase as another authorization requiring review.

Installing the patch addresses the vulnerable wallet behavior; it does not reverse a payment already sent to an attacker. The practical priority is to update before further signing and investigate suspicious transaction details before approving another payment. Software verification and recipient verification serve different purposes, and both belong in the payment workflow.

How did four matching address characters conceal a payment switch?

The Electrum payment switch used a forged pending transaction to turn a manual fee increase into authorization for a different recipient. Both reports described attacker addresses matching the intended recipient’s final four characters, making a suffix-only comparison insufficient to distinguish the destinations . The matching characters explain the visual resemblance; they do not establish how each affected user checked the address. The decisive action was signing the replacement payment, rather than merely seeing the misleading entry in the wallet’s history. The maintainers’ security advisory describes the following sequence.

1. A malicious server suppresses the intended payment. The server interferes with the legitimate payment and supplies misleading transaction information to the wallet. This puts the attacker in a position to influence what the user sees as a pending payment, without obtaining the user’s private keys.
2. The server supplies an invalid substitute paying the attacker. The substituted transaction redirects the destination, but it is not yet a valid payment authorized to spend the wallet’s funds. Its appearance in local history is therefore materially different from a valid transaction being accepted by the Bitcoin network. The vulnerable behavior allows that forged pending entry to become the starting point for another wallet action.
3. The user manually increases the fee through Replace-by-Fee. Replace-by-Fee is a mechanism for replacing an unconfirmed transaction with another transaction offering a higher fee. In this attack, the wallet constructs and signs a valid replacement from the malicious entry, preserving the attacker-directed payment. The fee-increase approval supplies the signing action that the invalid substitute lacked.

This distinction matters when interpreting the incident: the attacker’s initial substitute and the subsequently signed replacement are different transactions with different validity. The substitute misleads the wallet; the replacement authorizes the attacker-directed spend. The documented mechanism depends on that later manual fee increase, rather than showing that merely connecting to a malicious server automatically completes the theft.

An additional warning sign appeared in one report: the substituted transaction had zero fees . An unexpected fee-free entry warrants investigation, especially when it conflicts with the payment the user intended to send. However, that observation is neither a complete detection method nor proof of this exploit by itself. Treat it as a reason to inspect the destination and transaction details, rather than as an invitation to repair the entry by increasing its fee.

The trust boundary is transaction information, not custody of private keys. Electrum’s documentation states that private keys are never sent to its servers. A wallet can therefore retain its keys locally while still being misled into signing an unwanted payment. The practical lesson is to compare the complete destination against the intended recipient whenever signing a replacement: a familiar-looking ending cannot establish that the payment still goes to the right address.

Which Electrum users need to act first?

Electrum users running versions below 4.8.3 on untrusted servers should act first, especially if they have a pending payment and are considering a manual fee increase . Pause that signing decision and update before proceeding. The Electrum security advisory identifies the manual fee increase as the action that can turn the substituted transaction into a valid payment to the attacker. If your version or server configuration is unknown, establish both before signing again; uncertainty alone does not establish compromise.

The distinction between a trusted server and a merely familiar server matters. The Electrum maintainers state in their security advisory:

“Clients that connect to servers they trust (e.g. run their own) are not affected.” — Electrum maintainers, Electrum

For this decision, treat “trusted” as requiring an independent reason to trust the operator and the connection. A server you control and trust fits the maintainers’ example. A public server selected without such grounds does not become trustworthy simply because the wallet connects successfully or previously displayed plausible information. If you cannot explain why you trust the connected server, use the unknown category while you establish the details.

For an active trader with a time-sensitive outgoing payment, the practical recommendation is to resolve software and server uncertainty before using a fee increase to accelerate settlement. For someone already using a genuinely trusted server, the advisory supports lower urgency for this particular attack, while still recommending upgrades. For a patched user, an unexpected recipient remains a reason to stop and investigate. These categories prioritize the next action; they are not diagnoses of whether funds have already been redirected.

How do you install and verify the Electrum fix?

Download Electrum directly from its official website, verify the package’s signature using the site’s GPG instructions, and install the appropriate release for your device. The minimum fixed version for this advisory is 4.8.3; the official download page lists that release as of October 29, 2026 . The security advisory identifies versions below 4.8.3 as affected . If a newer official release is available when you download, distinguish the minimum security threshold from the current release rather than searching specifically for an older installer.

1. Navigate directly to the official website. Enter electrum.org in your browser and use its download links. This gives you the official starting point for the package, its signature, and the verification instructions.
2. Select the package for your platform. The official download page provides desktop and Android options. Choose the download appropriate to the device you intend to update; do not assume that instructions or packages are interchangeable across platforms.
3. Obtain the corresponding signature. Download the signature associated with your selected package. Keep track of which file it accompanies so that you verify the installer you actually intend to use.
4. Follow the official GPG verification instructions before installation. GPG signature verification checks whether the downloaded file was signed by the expected signing key. Follow the website’s instructions for identifying that key and verifying the package, including its recommendation to check the key’s fingerprint independently.
5. Install after verification is complete. If verification fails, or you cannot establish that the signing key is the expected one, pause installation and resolve that discrepancy. An unexplained verification result is not a completed check.

The distinction between a valid signature and a trusted signer matters. A fingerprint is an identifier for a signing key: checking it independently helps establish that the key you used belongs to the expected signer. According to Electrum’s verification guidance, the verification process establishes the signing relationship between the file and the key. Simply obtaining a key alongside a download does not replace the independent fingerprint check.

Signature verification also does not establish that software has no defects. It answers a narrower question about the downloaded file’s signer. Whether a release addresses this particular vulnerability is established by the maintainers’ advisory. Treat package verification and selecting a fixed release as complementary checks.

Before returning to trading or withdrawals, complete this installation checklist:

• Complete verification: check the package signature and independently confirm the expected signing-key fingerprint.
• Install the appropriate official release: make sure the verified package is the one you install.
• Reopen Electrum and confirm the installed version: downloading an update alone does not establish that the application you are running has changed.
• Review pending payments before signing: compare their destinations and amounts with your intended payments, including before any fee increase, as the advisory recommends.

What should you check before increasing a Bitcoin transaction fee?

Before increasing a Bitcoin transaction fee, review the full recipient address, recipient amount, proposed fee, and any destination changes in the transaction presented for signing. Treat a Replace-by-Fee (RBF) fee increase as a fresh payment authorization: the Electrum exploit relies on that later signing action to turn a forged pending entry into a valid attacker-directed payment, according to the Electrum security advisory. A familiar-looking pending payment is insufficient evidence that its replacement sends funds where you intended.

Use this checklist at the signing step, with the intended payment details available separately:

• Full recipient address: Compare the entire destination against the address obtained through a trusted recipient channel. Do not use the pending transaction itself as your reference. Both reports described in the advisory involved attacker addresses matching the intended destination’s final four characters . Checking only that suffix would therefore miss the reported substitutions.
• Recipient amount: Confirm that the amount going to the intended recipient matches your payment instructions. If it differs, establish why before authorizing the replacement; do not assume that selecting a fee increase explains every change.
• Proposed fee: Read the fee you are approving and distinguish it from the amount delivered to the recipient. A fee adjustment should receive deliberate review, even when the interface presents it as routine transaction maintenance.
• Unexpected destinations: Investigate any unfamiliar destination or unexplained output change. If you cannot determine what a displayed output represents, pause instead of inferring that it belongs to you.

If anything fails the check, do not sign the fee increase. A mismatched address, unexpected amount, or suspicious pending entry should trigger investigation. Establish which application version is actually installed, then apply the verified fix before reassessing: the advisory identifies versions below 4.8.3 as affected . Obtain the release through the official Electrum download site. Updating is a prerequisite for reassessment, not evidence that an unfamiliar recipient is legitimate.

Keep transaction-status investigation separate from signing approval. An external status check can help establish whether the original payment was broadcast or confirmed, but it cannot replace reviewing the actual replacement transaction. Electrum’s documented trust model distinguishes verification of confirmed transactions from the main server’s role in supplying unconfirmed transaction information. A pending label should not decide whether you authorize a destination.

Do not blindly recreate the payment while its original status remains unresolved; it may already have been broadcast. Resume only when you understand the existing payment’s status and can reconcile the proposed transaction with your intended recipient, amount, and fee. For a routine fee increase, the practical decision is straightforward: if you cannot explain what you are signing, stop.

Should you use public Electrum servers or your own trusted server?

A verified, patched Electrum client with public servers is a practical immediate choice for users who want to resume normal wallet use without operating infrastructure. A self-operated trusted server is an additional option for users prepared to maintain it. Electrum’s advisory states that clients connected to trusted servers, such as their own, are unaffected by this attack; that qualification concerns the malicious-server attack described in the advisory . It should not replace installing the fix or checking what you sign.

The useful architectural detail is that Electrum describes connections to approximately 10 servers, while one main server supplies wallet history and broadcasts payments . Those connections do not mean every pending payment undergoes independent checking across all connected servers. The Electrum FAQ distinguishes the main server’s role from the wider connection set. For a trader deciding whether to approve a replacement transaction, the relevant question is who supplies the pending-payment information—not simply how many servers appear connected.

Simple Payment Verification, or SPV, is the method Electrum uses to check a transaction’s inclusion in the blockchain through cryptographic proofs. Confirmed transactions receive that verification, whereas the documented trust model assigns unconfirmed transaction information to the main server. These are different evidence states: a pending entry is not equivalent to a payment verified as included in a block. Electrum also states that private keys are never sent to its servers (source: Electrum documentation). Keeping keys local and assessing server-supplied transaction information are separate responsibilities.

The comparison follows the documented server architecture and the advisory’s trusted-server qualification. “Public” describes who operates the server; it does not establish that a particular server is malicious. Likewise, operating a server creates an ongoing maintenance responsibility rather than removing the need for transaction review.

For most users seeking a practical immediate response, prioritize a verified patched client from the official download site and careful destination, amount, and fee checks whenever signing. Consider a self-operated server when controlling the source of unconfirmed transaction information justifies the administration involved. Make that infrastructure decision according to your maintenance capacity; do not delay the wallet update while planning it.

What does Electrum 4.8.3 validate, and what remains outside the fix?

Electrum 4.8.3 verifies signatures for wallet-owned inputs in unconfirmed transactions before accepting those transactions into local history. This blocks acceptance of the forged pending payment used in the reported redirection attack; it does not fully validate incoming unconfirmed transactions whose inputs belong to other wallets . The distinction matters because a wallet’s pending-transaction display and a confirmed payment represent different levels of evidence. The patch strengthens the checks applied when a transaction claims to spend your wallet’s funds. It does not make every incoming entry trustworthy simply because a server reports it.

A transaction input identifies funds being spent; its signature supplies authorization to spend them. In plain language, the added check asks whether a pending transaction spending your wallet’s funds actually carries valid signatures before allowing it into the wallet’s history. The maintainers’ advisory describes an attack in which a malicious server substituted an invalid transaction, then relied on the user increasing its fee to produce a valid payment to the attacker. Rejecting that forged entry interrupts the sequence before it can become the basis for the fee increase.

The implementation is reviewable: commit 90fe30822561e515a9d2d6e5a352cc07780999eb changes seven files and includes tests . Those details establish the scope of the published patch, rather than proving that every wallet security issue is resolved. For a trader deciding what to trust, the relevant improvement is the signature check itself, not the size of the change.

An incoming unconfirmed payment requires a different interpretation. Its inputs may belong entirely to the sender, placing it outside the patch’s wallet-owned-input checks. According to Electrum’s documented trust model, the main server supplies unconfirmed transaction information, while confirmed transactions receive Simple Payment Verification, which checks inclusion in the blockchain. A pending incoming entry therefore indicates a reported transaction, not equivalent evidence of a confirmed payment. When deciding whether to release goods, credit a counterparty, or treat a transfer as received, distinguish that pending status from confirmation.

Keep the controls separate when choosing your operating setup:

• Patched client: addresses the transaction-acceptance flaw by checking signatures on wallet-owned inputs before admitting unconfirmed transactions to local history, as documented in the patch.
• Trusted server: addresses the malicious-server condition; maintainers identify clients connected to trusted servers as unaffected by this attack in the advisory.
• Full transaction review: addresses lookalike destinations when signing. Follow the maintainers’ guidance to verify destination addresses and amounts, including during fee increases.

What should you do if an Electrum payment already looks wrong?

Stop further signing if an Electrum payment shows an unexpected destination or unexplained transaction details. Preserve the evidence and establish the transaction’s status before deciding what to do next. The Electrum advisory describes an invalid substituted transaction becoming a valid attacker-directed payment when the user signs a fee increase; another signature can therefore change the outcome.

1. Pause signing: Do not approve a fee increase or send a replacement payment while the destination remains unexplained. An unexpected entry is a reason to investigate, not a reason to retry automatically.
2. Preserve the details: Record the intended recipient’s full address, the amount, the displayed destination, any transaction identifier, and the wallet’s status message. Keep screenshots and relevant correspondence so assistance can address the actual transaction.
3. Determine the status: Establish whether the suspicious entry is invalid, pending, or confirmed. A wallet-history entry alone does not establish confirmation: Electrum’s documentation distinguishes server-supplied unconfirmed information from confirmed transactions checked through Simple Payment Verification.
4. Compare the full destination: Check the actual transaction output against the intended address using a recipient record you trust. Do not rely on a familiar-looking ending. If the addresses differ, preserve that discrepancy and seek assistance before signing anything else.

The advisory identifies GHSA-6jp4-8v48-cc5v as High severity and lists CVE-2026-117601. Maintainers received two reports, but the advisory provides neither a loss amount nor a comprehensive victim count . Those limits matter: the documented reports establish exploitation, without establishing its total scale.

• October 11, 2026: Initial disclosure, according to the maintainers’ advisory .
• October 18, 2026: Raju-K12 reported financial loss .
• October 23, 2026: The security update carries this date in the release notes .
• October 24, 2026: Binaries and public disclosure followed .
• October 29, 2026: The official download site listed Electrum 4.8.3 as the latest release when checked .

Choose the next action that fits your situation. If your wallet runs a version below 4.8.3, install a verified fixed release before further signing . Follow the official download site’s signature-verification guidance. If already patched, retain full-address and amount checks whenever signing. If a payment appears attacker-directed, preserve evidence and seek case-specific assistance through independently verified support channels. Updating addresses the vulnerability; it does not establish the fate of an earlier payment. Resolve the destination and status before authorizing another transaction.

Frequently asked questions

Which Electrum version fixes the transaction redirection vulnerability?

Electrum 4.8.3 fixes the vulnerability; the maintainers’ advisory identifies versions below 4.8.3 as affected . The official download site listed that version as the latest on October 29, 2026; check there for subsequent releases before installing .

Is checking the last four characters of a Bitcoin address enough?

No. Both reports described attacker addresses matching the intended recipient’s final four characters, according to the security advisory . Compare the full recipient address against your independently verified destination and check the amount whenever signing, including when increasing a transaction’s fee.

Did the malicious Electrum server obtain users’ private keys?

The reported exploit did not require the server to obtain private keys. Electrum’s documentation says private keys are never sent to servers. Instead, the malicious server supplied forged pending transaction information; the user’s subsequent fee-increase action caused the wallet to sign a valid payment to the attacker, as described in the maintainers’ advisory.

Does using my own Electrum server protect against this attack?

Yes, provided the server is trustworthy. The maintainers state that clients connected to trusted servers, such as their own, are unaffected by this attack. Ownership alone does not establish trust: the qualification concerns the server actually supplying your wallet’s transaction information. Keep a verified, patched client installed and continue checking the recipient address and amount whenever signing.

Will updating Electrum recover Bitcoin already sent to an attacker?

No. Updating fixes the vulnerable transaction-acceptance behavior; it does not reverse an already confirmed Bitcoin payment. The patch adds signature checks for wallet-owned inputs in unconfirmed transactions. The advisory distinguishes the invalid transaction supplied by the server from the valid attacker-directed payment created through fee replacement. Establish which transaction was actually broadcast, its destination, and whether it has confirmed before deciding what to do next.

Enjoyed this article? Subscribe to get new stories by email whenever they're published.

Subscribe