Four address characters matched in Electrum's fee-bump theft

A familiar address ending can make a changed destination easy to overlook. In the reported Electrum attack, a routine attempt to speed up a payment could become approval to send funds to someone else.

How did matching four address characters help redirect an Electrum payment?

A malicious server substituted an invalid outgoing payment in Electrum’s history; a subsequent user-authorized fee increase could make that payment valid. In both reported cases, attacker addresses matched the intended recipient’s final four characters, but that resemblance did not make the complete addresses identical .

Quick Answer: Matching the final four address characters helped disguise a substituted recipient in the reported Electrum fee-bump attack . A malicious server inserted an invalid payment that a later fee increase could authorize. Upgrade before another fee increase, and compare the complete destination and amount against independently retained payment instructions.

The official security advisory describes two reported cases, including one theft—not two confirmed thefts. The loss report received on October 18, 2026 involved a substituted transaction with zero fee . That distinction matters: the incident establishes an exploited authorization flaw, without establishing how widely attackers used it.

Replace-by-Fee is a mechanism for replacing an unconfirmed transaction with a higher-fee transaction. In this attack, the server could withhold the legitimate outgoing payment and present an invalid transaction paying the attacker instead. When the user requested a fee increase, the vulnerable wallet could sign the substituted payment, making it valid, according to the developers’ explanation. The critical step was obtaining authorization through the fee-bump workflow; this was not evidence that Bitcoin’s cryptography had been broken.

The practical implication is straightforward: a recognizable suffix is insufficient evidence that the recipient is correct. Treat a fee increase as another signing decision, with the destination and amount deserving the same scrutiny as the original payment. Before approving:

• Compare the complete destination with the address in your independently retained payment instructions, rather than relying on its ending.
• Check the recipient amount against the intended payment, separately from the proposed transaction fee.
• Pause if anything differs. A familiar-looking history entry should not substitute for checking the payment you are about to authorize.

These checks implement the developers’ recommendation to verify destinations and amounts whenever signing, including during fee increases.

Before another fee increase, upgrade to Electrum version 4.8.3 or a subsequent official release; the advisory identifies earlier versions as affected . According to CoinDesk’s October 26 reporting, the stolen amount remained undisclosed, and a broader victim count had not been established .

Is your Electrum setup exposed to the reported fee-bump attack?

Your Electrum setup is exposed to the reported scenario if it runs an affected version, receives a substituted outgoing transaction from a malicious server, and you authorize that transaction through a fee increase. The advisory identifies versions earlier than 4.8.3 as affected, but an affected installation alone does not establish that a theft occurred . The practical distinction is between software that needs updating and a payment that needs investigation. Check your installed version, your server arrangement, and what you have actually signed before deciding which situation applies.

The following comparison separates software status from the conditions required for the reported attack. Its exposure assessments follow the Electrum security advisory.

A trusted server changes the assessment because the reported mechanism depends on malicious transaction information reaching the wallet. The developers explicitly place clients using trusted servers, such as their own, outside this attack scenario. That is a narrow statement about this mechanism: owning a server does not establish that every wallet operation is safe. Updating remains the appropriate recommendation for these clients too, alongside checking destinations and amounts whenever signing, as the advisory recommends.

Use these decision criteria before authorizing another pending-payment action:

• Installed version: Read the version shown by your client. Compare it with the advisory’s patched release, 4.8.3 .
• Confidence in server trust: Establish why you trust the server supplying wallet history. If you cannot establish that trust, treat the arrangement as uncertain.
• Pending outgoing payment: Determine whether you are about to increase a payment’s fee. That signing action is central to the disclosed theft mechanism.
• Unexpected recipient or amount: Compare the proposed payment with your intended destination and amount. An unexplained difference is a reason to stop before signing.
• Replacement already signed: Establish whether you merely viewed the transaction or authorized a replacement. If you signed an unexpected payment, investigate the transaction rather than treating an update as the complete response.

These checks apply the advisory’s distinction between affected software and the user-authorized attack path. Uncertainty is a reason to verify the setup before another signature; it is not evidence by itself that funds have been stolen.

Why could a fee increase authorize a different recipient?

An Electrum fee increase could authorize a different recipient because the wallet created a replacement from a substituted transaction in its history. Replace-by-Fee (RBF) is a way to replace an unconfirmed payment with a transaction offering a higher fee; signing that replacement authorizes its payment details. In the reported attack, the malicious server supplied those details before the user requested the fee bump. The wallet then signed a payment to the attacker, as described in the Electrum security advisory. The practical consequence is that the destination and amount remain essential review fields whenever a replacement is signed.

The advisory describes a sequence in which misleading wallet history becomes the basis for a real authorization. The distinction between displaying a payment and signing it is central to understanding the failure:

1. The user creates a legitimate payment. The wallet sends the intended transaction to its main server for broadcast, expecting it to reach the Bitcoin network.
2. The malicious server withholds that payment. It supplies an invalid substitute directing funds to the attacker instead of the intended recipient.
3. The wallet admits the substitute to history. The affected client displays it as an unconfirmed outgoing payment without checking the invalid signatures. The legitimate payment is absent from that view.
4. The user requests a fee increase. Believing the displayed entry represents the intended payment, the user initiates a replacement to speed up confirmation.
5. The wallet signs the replacement. That signature can make the attacker-directed payment valid. The authorization comes from the user’s wallet during the fee-bump workflow. This sequence is documented in the developer advisory.

The trust boundary explains how the substitute reached the screen. Electrum normally tries to maintain approximately 10 server connections, but selects one main server to supply wallet history and broadcast payments . Other connections provide block-header notifications and fee estimates; they do not establish independent agreement on every pending payment. According to Electrum’s documentation, the main server can also omit transactions. A populated history screen therefore does not establish that every displayed unconfirmed transaction has passed the checks a reader might assume.

“The server is trusted about unconfirmed transactions.” — Electrum developer documentation

Confirmed transactions receive Simple Payment Verification (SPV), the lightweight verification method Electrum uses to check their inclusion in the blockchain. That differs from trusting a server’s report about a pending payment. The documentation’s distinction matters because the malicious substitute entered the wallet’s unconfirmed history before the user authorized its replacement.

This was a transaction-authorization failure: the substitute initially had invalid signatures, and the wallet subsequently supplied a valid signature through the fee increase. The reported mechanism provides no evidence that Bitcoin’s cryptography was broken. For a trader, the decision rule is straightforward: approve a replacement only when its full destination and payment amount match the intended transfer. Treat the signing screen as a fresh spending decision, even when the immediate goal is simply faster confirmation.

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

Electrum 4.8.3 blocks the reported fee-bump exploit by verifying signatures for wallet-owned inputs in unconfirmed transactions before admitting those transactions to local history. This prevents a forged outgoing payment from becoming the transaction a user later authorizes through a fee increase . The correction targets the point where untrusted transaction data entered the wallet’s history. It does not extend the same validation to incoming transactions or turn Electrum into a full consensus-validating node .

The corrective commit, 90fe30822561e515a9d2d6e5a352cc07780999eb, adds the signature check for inputs spending coins belonging to the wallet . A transaction input identifies coins being spent; its signature supplies authorization for that spending. Checking this authorization before accepting the outgoing transaction into local history closes the entry point used by the reported substitution. The protection therefore acts before a user reaches the replacement-signing decision, rather than relying solely on the user noticing a changed recipient.

The official security advisory rates the vulnerability High severity and identifies it as GHSA-6jp4-8v48-cc5v and CVE-2026-117601. It lists versions earlier than 4.8.3 as affected . These identifiers let readers match an update notice to the specific vulnerability, rather than assuming any reference to a wallet security update covers this mechanism.

• October 11, 2026: Developers received the initial private report, before recognizing the fee-bump attack vector, according to the advisory timeline .
• October 18, 2026: Developers received the loss report from Raju-K12, documented in the official advisory .
• October 23, 2026: The release notes date the security update to this day, corresponding to the Git tag .
• October 24, 2026: The binaries were released and the vulnerability was publicly disclosed, according to the disclosure timeline .

The release-note date and binary-release date describe different milestones for the same security update, not separate fixes. The earlier date marks the tagged release; the later date marks availability of the binaries and public disclosure .

For an upgrade decision, distinguish the corrected mechanism from broader trust assumptions. Rejecting an improperly signed outgoing transaction addresses the reported route into a malicious fee replacement. It does not establish that every transaction a server displays is valid, complete, or ready to rely on. The developers recommend upgrading while continuing to check destination addresses and amounts whenever signing, including fee increases . Treat the patch as a necessary software correction and transaction review as an ongoing responsibility.

What should you check before increasing an Electrum transaction fee?

Before increasing an Electrum transaction fee, confirm that your client is patched, retrieve the original payment instructions, and review the complete destination address, intended payment amount, and proposed replacement fee. Treat the fee increase as a fresh signing decision: the developers recommend checking destinations and amounts whenever signing, including fee replacements . The practical question is whether the transaction awaiting approval still matches the payment you intended to make. A familiar-looking history entry is not enough to answer that question.

1. Confirm the installed release is patched. Check the version of the application you are actually running, rather than assuming a downloaded installer completed the update. The advisory identifies versions earlier than 4.8.3 as affected and names 4.8.3 as the patched release . If the installed client is affected, stop the signing workflow and update before proceeding.
2. Retrieve the original payment instructions independently. Open the invoice, saved payment request, or recipient communication you used when preparing the payment. Do not use the wallet’s transaction history as the sole reference: the reported exploit placed a substituted outgoing transaction in that history . If your retained instructions are incomplete, confirm them with the intended recipient through an established channel before signing.
3. Compare the complete destination address. Match the proposed recipient address against the independently retained instructions from beginning to end. Expand any shortened display before making the comparison. Both cases described by the developers involved attacker addresses matching the intended recipient’s final four characters . Neither a familiar prefix nor a familiar suffix establishes that the full destination is correct.
4. Verify the intended payment amount. Compare the amount going to the recipient with the original payment instructions. Read it separately from the network fee and any displayed total debit. The developers’ signing guidance calls for checking both destination and amount. An unexplained difference is a reason to pause, even if the address appears correct.
5. Inspect the proposed replacement fee. Read the fee you are about to authorize and distinguish it from the recipient’s payment. An unexpected zero fee deserves investigation: the reported theft involved a substituted transaction with zero fee . That observation is neither a universal attack signature nor a sufficient detection test. A plausible fee cannot substitute for checking the destination and amount.

Conceptual example—not actual Bitcoin addresses: imagine an intended address represented as “recipient-specific characters … wxyz” and a different address represented as “attacker-specific characters … wxyz.” The matching ending tells you nothing about whether the preceding characters match. These labels illustrate the visual trap; they are not usable addresses or addresses from the incident. Check the entire destination rather than treating a recognizable fragment as recipient identity.

If the recipient, amount, or fee disagrees with your expectations, do not sign the replacement. Update an affected client, then reconcile the pending payment with the intended recipient using independently retained details. The corrective change adds signature verification for wallet-owned inputs before unconfirmed transactions enter local history . Installing that correction does not undo a payment already authorized or confirmed. Resume signing only when the transaction details agree with the payment you intended.

Which Electrum setup fits your transaction habits and technical skills?

The best Electrum setup is one you can maintain reliably while checking every payment you authorize. For occasional users, the editorial recommendation is a patched client and a repeatable full-address-and-amount review. Frequent fee-bump users should apply that review at every replacement signature; technically capable users can also operate their own server to address the malicious-server dependency in this reported attack. Electrum identifies version 4.8.3 as the security update and says clients using trusted servers, including their own, are outside the reported attack scenario . Server choice adds a trust decision; it does not replace careful signing.

The comparison below separates the documented security distinctions from editorial judgments about maintenance and suitability. Electrum’s main server supplies wallet history and broadcasts payments, and its documentation says that server is trusted for unconfirmed transactions. Multiple connections therefore do not make pending-payment history independently verified across all connected servers. See Electrum’s server-trust documentation.

*Maintenance and user-fit assessments are editorial recommendations. Security distinctions follow the official security advisory and the documented server-trust model.

For occasional users, prioritize a process you will actually follow: keep the official client updated, retain the intended payment details independently, and compare them with the signing request. There is no reason to treat a public-server connection by itself as proof that funds were redirected. The advisory describes an attack involving malicious server behavior and a subsequent user-authorized fee increase, rather than compromise established merely by connection type.

For frequent fee-bump users, make recipient and amount review mandatory whenever a replacement requests authorization. Repetition can make a fee adjustment feel routine, but the decision still concerns the payment being signed. A genuinely trusted server is an additional option where that trust can be established; the developers’ signing guidance still calls for checking destination addresses and amounts.

For technically capable users, operating a server backed by a Bitcoin node is a reasonable editorial recommendation when maintaining that infrastructure fits their skills and transaction habits. Ownership addresses the outside-server dependency identified here, but it does not remove configuration mistakes, maintenance failures, or incorrect signing decisions. Choose the additional infrastructure when you can sustain it, and preserve the same payment-review discipline regardless of who operates the server.

What should you do if you already approved a suspicious fee increase?

If you already approved a suspicious Electrum fee increase, pause further signing, preserve the transaction details, and independently establish whether the replacement payment is pending or confirmed. Installing the security update addresses the documented validation flaw; it does not establish the status or recoverability of an already signed payment. The attack depended on a user signing the substituted transaction during a fee increase, making reconciliation the immediate priority .

Use this checklist to organize your next steps before approving another transaction or seeking assistance:

• Pause further signing. Do not approve another fee increase or an unfamiliar payment while investigating the destination mismatch.
• Record both transaction identifiers. Preserve the original payment’s transaction ID and the suspicious replacement’s transaction ID, where available. Keep their details separate so you can compare their outputs.
• Retain the intended payment details. Save the recipient’s complete address, expected amount, and original payment request. Compare against that record rather than a shortened address displayed in transaction history.
• Document your setup. Note the installed wallet version and server configuration associated with the incident before changing them.
• Check the transaction’s status independently. Establish whether the suspicious replacement is pending or confirmed, and reconcile the original payment as well.

The original server’s history should not be your sole reconciliation record. Electrum’s documentation says its main server supplies transaction history and can omit transactions; unconfirmed transactions involve a different trust boundary from confirmed payments. Use a trusted independent source to check the recorded transaction IDs rather than treating a missing history entry as evidence that a payment was canceled. See Electrum’s server-trust documentation. Limit disclosure to what is necessary for the check; avoid sharing a complete wallet history or unrelated addresses.

Keep patching separate from incident resolution. Electrum 4.8.3 adds the documented protection through signature verification for wallet-owned inputs before unconfirmed transactions enter local history . The corrective code change addresses that admission step. Updating does not itself cancel or reverse an already signed transaction, and a pending status should not be treated as an assurance of recovery.

At this article’s October 28, 2026 update, the advisory describes two reported cases, including one theft . CoinDesk’s October 26 reporting said developers had not disclosed the stolen amount or identified the malicious servers . Seek help through official project support channels, using the official advisory as the incident reference. Never share seed phrases or private keys. Preserve the evidence, verify the payment’s status independently, and update before resuming routine signing.

Frequently asked questions

Which Electrum versions are affected by the fee-bump vulnerability?

The official advisory identifies versions earlier than 4.8.3 as affected; version 4.8.3 contains the fix, with binaries released on October 24, 2026 . The October 23, 2026 date in the release notes corresponds to the Git tag, rather than the binary release .

Can an attacker redirect funds just because I open Electrum?

Opening Electrum alone does not complete the documented attack. A malicious server must substitute an invalid outgoing transaction in the wallet’s history, and the user must subsequently authorize a fee increase that signs the substituted payment. That is the mechanism described in the official advisory; it is not a conclusion about every possible wallet attack.

Why is checking the last four characters of a Bitcoin address insufficient?

Different Bitcoin addresses can share the same ending. Both reported cases involved attacker addresses matching the intended recipient’s final four characters . Compare the complete destination against independently retained payment instructions, and check the amount whenever signing—including when increasing a fee—as recommended in the developer advisory.

Does connecting to several Electrum servers prevent this attack?

No. Multiple connections do not mean every server independently validates each pending payment. Electrum’s documentation explains that a main server supplies wallet history and broadcasts payments, and that the client trusts this server for unconfirmed transactions. Confirmed payments receive Simple Payment Verification checks, but those checks do not establish the validity of an unconfirmed outgoing payment.

Does updating Electrum recover funds from a substituted payment?

No. The corrective change verifies signatures on wallet-owned inputs before admitting unconfirmed transactions to local history, blocking the documented forged-history mechanism. It does not undo previously signed payments or recover funds already transferred. If you approved a suspicious fee increase, establish the payment’s status independently before considering possible responses.

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

Subscribe