Electrum Patched a Signing Bug. The Disclosure Is Still Broken.

Electrum shipped a fix. That is the least interesting sentence in this story.

The interesting sentence is this: a malicious Electrum server could substitute a payment the user never intended to make, raise the transaction fee attached to it, and get the user to sign both. The developers acknowledge that one user reported a loss. The same summary that announces the patch does not announce a CVE identifier, an affected version range, a fixed version number, or a link to an advisory.

That is not a documentation gap. A patch you cannot identify is not a patch. It is a rumor with a commit hash attached to it.

I have spent nine years reading security disclosures and four of them getting paid to do it. The pattern here is not exotic. The bug gets fixed. The process that would let anyone outside the project verify the fix never runs. Read the code, ignore the roadmap — and in this case, ignore the release notes too, because there are none you can cite.

Context: what Electrum is, and what SPV actually promises

Electrum has been in production since 2011. It is the oldest continuously maintained Bitcoin light wallet, written in Python, and for a large cohort of users it is simply the default. It does not download the chain. It downloads block headers, then asks a third-party server for Merkle proofs that a given transaction exists in a given block.

Those servers — ElectrumX, Electrs, and Fulcrum are the common implementations — provide headers, broadcast transactions, report mempool state, and estimate fees. The client ships with a built-in list of default servers. Users can add their own. Nobody audits the list continuously, because continuous auditing of a volunteer server network is not a thing that gets funded by donations.

The architecture is called SPV, simplified payment verification. It exists because most people will not run a full node, and pretending otherwise has cost this industry a decade of bad user experience and a certain amount of moral posturing.

The SPV security model is usually stated badly. It does not promise that the server is honest. It promises that the server's dishonesty is bounded. The bounds are cryptographic:

• A server cannot forge a valid proof-of-work chain.
• A server cannot forge a Merkle proof for a transaction that is not in a block.
• A server cannot spend your coins, because it never sees your private keys.

There is a fourth bound, and it is not cryptographic. It is an engineering invariant: a server cannot cause you to sign a transaction you did not intend to sign. That one is enforced by code, not by mathematics. It is called WYSIWYS — what you see is what you sign. The rendered transaction and the serialized transaction must be the same object, byte for byte, at the moment the private key touches it.

The Electrum incident is a failure of the fourth bound. The first three held.

That distinction matters more than the bug itself, and it will be the first thing lost in the retelling.

Core: the failure was in the client, not in the cryptography

The invariant that broke

Every wallet carries two representations of a transaction. There is the rendered object — the one the interface draws, with the recipient address, the amount, and the fee, in a font you can read. And there is the serialized object — the byte string that gets hashed and signed.

WYSIWYS holds if and only if the signing path operates on exactly the object that was rendered and confirmed. Not a copy. Not a reconstruction. Not a re-fetch from the network. The same object, passed through without mutation.

In Electrum's flow, the client builds an unsigned transaction, consults the server for previous outputs, mempool state, and fee data, renders the result, waits for confirmation, serializes, and signs. Every point where server-supplied data enters the pipeline after rendering — or alongside it, through a second code path that the renderer does not read from — is a candidate for a WYSIWYS break.

The disclosed behavior is the exact signature of that bug class: a fake payment, an inflated fee, a signature given without the user's awareness. Cryptography protects you from the server. Code protects you from yourself. This was the second category.

Reconstructing the chain

Working only from what the disclosure actually says, the attack decomposes into five steps:

1. The user connects to a malicious Electrum server. Either the attacker got onto the default list, or the user added the server manually, or the client rotated into it.
2. The server substitutes or fabricates payment content in the data it returns.
3. The server raises the transaction fee in the same payload.
4. The client renders something that does not match what it will sign — or renders correctly and signs a different serialization. The user confirms.
5. The transaction broadcasts. The payment lands at the attacker's address. The fee lands with whichever miner includes the block.

The step that determines blast radius is step one, and the disclosure does not resolve it. If the attacker needed a user to add a server manually, the attack requires social engineering, and the population at risk is small and self-selected. If the attacker got onto the default server list, the attack is passive, and the population at risk is everyone who never overrode the defaults. Those are different incidents with materially different severity ratings, and the summary treats them as one.

The fee is not noise. It is a second revenue stream.

Most commentary will treat the fee inflation as an aggravating detail. It is more interesting than that.

A single signature produces two cash flows. The payment goes to the attacker's address. The fee goes to the miner of the block that includes the transaction. If the attacker operates a miner, or has an arrangement with one, the fee comes back. If not, the fee is a donation to a stranger.

That asymmetry tells you something about the attacker's model. One signature, two revenue streams: the payment is mandatory, the fee is optional. An attacker who captures both has an incentive to maximize the fee. An attacker who captures only the payment has an incentive to keep the fee plausible. [Inference. Confidence: medium.]

The second case is worse for detection. A transaction with an anomalous fee is a red flag that a careful user might notice on a block explorer. A transaction with a fee inside the normal range for the prevailing mempool is invisible, and the victim has no reason to look at it twice. The attacker who understands this will not maximize the fee. They will calibrate it.

The disclosure does not say whether the observed loss involved an abnormal fee. That single data point would tell us whether we are looking at a profit-maximizing operator or a camouflage-conscious one, and it would tell us whether the victim reported because of the loss or because of the fee.

The economics of running a malicious server

Nobody in this discussion has priced the attacker's cost structure, which is the part that determines whether this stays a curiosity or becomes a campaign.

The marginal cost of operating an Electrum server is low. A small VPS, a synced node or a proxy to a public backend, and an afternoon of configuration. The marginal cost of getting onto the default list is higher — it requires being noticed, and the list is curated — but not prohibitive for anyone with patience and a plausible-looking hostname.

The expected revenue per victim is bounded by the victim's balance. A wallet with a long history and a large balance is worth more than a fresh one, which means the attacker's optimal targeting is not random. It is balance-weighted, and balance-weighted targeting against a server that can see the addresses you query is trivially achievable.

That combination — low fixed cost, near-zero marginal cost, balance-weighted targeting — is the profile of an attack that gets run repeatedly once someone proves it works. The disclosure says one user reported a loss. The attacker's economics say the number that matters is how many users connected, not how many complained.

What "patched" actually means, precisely

There are four layers between a fixed commit and a fixed user, and each one has its own lag.

1. The commit. The code change exists in the repository. This is the layer the disclosure is describing.
2. The tagged release. A version is cut, numbered, and published. If the summary does not give you the number, this layer is invisible to you.
3. The signed binary. The release is built and signed, with a GPG signature and a published checksum. Users who verify signatures get the fix. Users who do not verify signatures get whatever the download page served them.
4. The distribution package. Linux repositories, package managers, and third-party bundlers pick up the new version on their own schedules, sometimes months later, sometimes never.

The disclosure describes layer one. It gives you no information about layers two, three, or four. That is the practical content of "a patch has been released" — a statement that is true at exactly one layer and unverifiable at the three that matter to a user.

From the outside, "we fixed it quietly" and "we never fixed it" have the same observable signature. I have killed vendor relationships over exactly this. In a 2025 review I ran on an AI-content platform backed by a large sponsor, the technical findings were serious but survivable. What ended the deal was the disclosure posture: the team had patched three issues silently and could not produce a timeline for any of them. My note to the investment committee was one line, and it was not about the bugs.

Electrum is not that vendor. It is a volunteer project with a real security history and a real patch. But the observable signature is identical, and the user cannot tell the difference.

The disclosure failure is the part that will outlast the bug

Here is what a coordinated disclosure looks like in 2026. A CVE identifier. A CVSS vector. An affected version matrix with an upper and lower bound. A fixed version. A dated advisory at a stable URL. A signed release with a GPG signature and a published checksum.

Here is what we got: a patch exists, and one user reported a loss.

The absence of a version range is not a documentation gap. It is a remediation blocker. A user who reads the summary cannot answer the two questions that matter: am I affected, and what do I upgrade to. That is the entire function of an advisory. Everything else is decoration.

The absence of a CVE has downstream consequences that the maintainers may not have modeled:

• Vulnerability aggregators will not index it, so it will not surface in the feeds security teams actually monitor.
• Distribution security trackers will not flag the packaged version, so Linux users who installed from a repository have no signal at all.
• SBOM scanners will not match it, so any organization that inventories its software will not find it in the inventory.
• Enterprise vulnerability management will not ticket it, because there is no ticket to open.

The patch exists in a channel that institutional users do not watch. For a wallet whose entire pitch is that you should trust it with your keys, that is a process failure with a longer half-life than the vulnerability.

The long tail is where the losses live

Suppose the fix is correct and complete. The vulnerability's half-life is still not set by the patch date. It is set by the slowest-upgrading cohort.

Desktop wallets do not have an app store. There is no forced update channel. A user downloads a binary from a website, verifies a signature if they are disciplined, and then runs that binary for years. Electrum has no telemetry to measure the distribution of client versions in the wild, and neither does anyone else.

That means the exploitable population declines on a curve nobody has plotted, toward an asymptote nobody has estimated. The 2018–2019 malicious-server campaign against Electrum — a different bug, the same trust boundary — ran for months and extracted funds from users who had not updated. The lesson from that episode was not "patch faster." It was "the population that does not patch is large enough to fund an attack on its own."

The patch date is when remediation begins. It is not when risk ends. Anyone treating the fix as a closing event is reading the wrong timestamp.

Downward propagation: the vulnerability class is portable, the patch is not

Electrum sits at a junction. Upstream, it depends on a server network it does not control. Downstream, its protocol and its code patterns are reused by ElectrumX, Electrs, and Fulcrum on the server side, and by Sparrow, BlueWallet, Wasabi, and a long tail of forks on the client side.

The bug therefore has two directions of travel.

Upward, the attack requires a malicious server, and the server ecosystem has no admission control and no reputation layer. Anyone can run one. Curation of the default list is not continuous auditing.

Downward, the trust assumption is inherited. A downstream client that made the same assumption about the display/sign boundary carries the same bug, and the Electrum client patch does not touch it. Nobody has published a survey of which downstream wallets render and sign through the same code path.

The vulnerability class is portable. The patch is not. This is the part of the story that will still be relevant in 2027, after the fee numbers are forgotten.

I have seen this pattern in a different domain. During my 2020 audit work on early yield-farming contracts, the interesting finding was never the specific re-entrancy path. It was that every fork inherited the path along with the code, and every fork's team believed their fork was different because they had changed the parameters. Parameters are not architecture.

"One user reported a loss" is a measurement of the reporting channel

The disclosure says one user reported a loss. That is a reporting statistic. It is not an incidence statistic, and treating it as one is the most common analytical error in this entire category.

Underreporting has at least five mechanisms here:

1. The victim cannot tell. A payment to an address they do not recognize, with a fee inside the normal range, looks like a mistake they made, not an attack they suffered.
2. The loss is below the cost of reporting. Filing a GitHub issue takes time and invites public scrutiny of your own operational security.
3. There is no clear channel. A GitHub issue is a bug tracker, not a victim intake process. An email to a maintainer is not a case number.
4. Language and jurisdiction. Electrum's user base is global; the maintainers' communication surface is English and GitHub-shaped.
5. Shame. Nobody wants to post "I signed a transaction I did not read" in public.

Every one of those mechanisms biases the count downward. The true figure is not one. It is one plus an unknown.

I ran into the same epistemic trap in 2021, when I analyzed 15,000 OpenSea transactions and found that roughly 85% of the volume was coordinated wash trading between linked wallets. The reported volume was a fiction in the upward direction. Here the reported victim count is a fiction in the downward direction. Both are measurements of a reporting channel, not of a system. The mistake is identical; only the sign flips.

The data to fix this is obtainable. You would look for on-chain patterns — payments to fresh addresses paired with fee levels anomalous for the prevailing mempool — and correlate them against known malicious server endpoints. Nobody has published that analysis. Until someone does, "one user" is a placeholder.

No token, no treasury, no compensation path

Electrum is free and open source, funded by donations. There is no token, no treasury, no insurance fund, no governance vote.

For once, the absence of a token economy is not a criticism. There is no Ponzi flywheel here to unwind and no supply schedule to interrogate. But the absence has a consequence that users do not price: there is no compensation path. Losses are terminal.

Compare the DeFi case. When a protocol is drained, there is often a treasury, a foundation, an insurance fund, or at minimum a token to dilute in a reimbursement vote. The reimbursement is frequently inadequate and the governance process frequently captured by whales, but a mechanism exists. Electrum has none of that. The only asset at risk is brand trust, and brand trust does not make victims whole.

The flip side is that a donation-funded project has no exit pressure and no capital ammunition. Security response capacity is a volunteer and part-time resource. That is a structural tension, not a moral failing: the attack surface grows with the user base, and the maintenance budget does not.

The market read: this is not a Bitcoin signal

Bitcoin's price is unaffected. There is no transmission path. The vulnerability does not touch the consensus layer, the issuance schedule, or any protocol rule. Wallets are application-layer software.

The only channel is sentiment, and sentiment without a balance-sheet link is noise. Volatility is just unpriced risk, and here there is no mispriced volatility to harvest because there is no instrument to trade it with.

The real market effect is a marginal shift in wallet category share. Every light-wallet incident pushes some users toward hardware signing devices, some toward self-hosted nodes with private servers, and some back toward custodial platforms. That is a slow, trend-level migration, not a trade. The beneficiaries — hardware vendors, node-in-a-box sellers, exchanges — mostly have no liquid token exposure, which means the thesis is correct and unmonetizable. That is the definition of a low-value signal.

Contrarian: the SPV model held, and the loudest critics have the wrong remedy

The reflexive take will be that this proves light wallets are unsafe and everyone should run a full node. That take is wrong in an instructive way.

Look at what actually failed. The server could not forge a chain. It could not forge a Merkle proof. It could not move funds without a signature. Three cryptographic bounds held under adversarial conditions. The fourth bound — the engineering invariant at the display/sign boundary — broke, was found, and was patched. A model that fails at the implementation layer and gets repaired is a model that is working, not a model that is broken.

The full-node purists are right about the architecture and wrong about the remedy. Telling a user to run a node does not fix the signing path in the wallet they are actually using, and it does not scale to the population that needs the protection.

Here is the blind spot nobody is naming. The mitigation that actually works against this bug class is not decentralization. It is a signing device with an independent screen. A hardware wallet renders the transaction on a different piece of hardware than the one that was compromised, so a client-side display break cannot propagate to the confirmation step. Hardware wallets did not win this round because they are more decentralized. They won because they added a second, independent rendering path.

That is defense in depth, and it comes with its own caveats. Blind signing, address truncation on small screens, and firmware trust all remain unsolved problems, and a hardware wallet that asks you to trust its vendor's firmware update channel has moved the trust boundary rather than eliminated it. But moving the boundary to a place where a display bug cannot reach the signature is a real improvement, and it is the least ideological conclusion available — which is probably why it will get less airtime than the full-node argument.

One concession, in fairness. Judging a disclosure process mid-flight is a category error, and a news summary is not an advisory. The maintainers may be preparing the CVE and the version matrix as I write this. But a summary was published, and publishing a summary without a version range is worse than publishing nothing, because it creates the impression that remediation is complete when the only thing that is complete is the commit.

Takeaway

Three things to watch, and one question.

Watch for the CVE and the dated advisory. If they never appear, treat the incident as unresolved regardless of the patch, because the population that needs the information will never receive it.

Watch the downstream clients. Sparrow, BlueWallet, Wasabi, and the fork ecosystem inherited the protocol and, plausibly, the assumption. A survey of their display/sign boundaries is the highest-value research nobody has done.

Watch whether the default server list acquires an actual audit process, with published criteria and named reviewers. Curation without publication is a trust-me mechanism wearing a technical costume.

And the question. If you cannot name the version you are running, and the maintainer cannot name the version that is fixed, what exactly did you patch?

Logic doesn't lie. The commit exists. The advisory does not. Those are different kinds of evidence, and only one of them is verifiable by anyone outside the room.