The bump is the payment.
@nunchuk_io posted at 08:30 UTC on October 31 that the new Nunchuk builds check a pending transaction before they will treat it as a fee bump. https://x.com/nunchuk_io/status/2116447801127379440. When I read it, that post had 59 likes, 12 reposts, 5 replies, 2 quotes, 12 bookmarks, and 4,876 impressions. The versions in the post are iOS 2.9.4, Android 2.9.3, and desktop 2.9.3. Invalid transactions returned by an Electrum server are rejected and reported to the user. A malicious server cannot present an invalid conflicting transaction as a legitimate fee-bump candidate.
Five minutes later the same account posted the store and GitHub links, and wrote that Nunchuk will never ask for your seed phrase or send you update links in DMs. https://x.com/nunchuk_io/status/2116448873304768779. When I read that one, 6 likes, 1 reply, 1 bookmark, and 512 impressions. That line is the right warning on an update day. It is not the bug.
The long note under the version list is mostly a multisig pitch, and it uses the Binance laptop sentence to get there. I wrote yesterday that the freeze is not a return. I am not redoing that one. The new part today is the check on a pending transaction.
What the history showed
Electrum published the advisory on October 24. https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v. High severity. CVE-2026-117601. Every version before 4.8.3. The fix is commit 90fe308, in 4.8.3. They tagged that version on October 23. Binaries and the public note came out on October 24. electrum.org lists 4.8.3 as the current release.
https://electrum.readthedocs.io/en/latest/faq.html already says the server is trusted about unconfirmed transactions. The client never sends private keys to a server, and it checks confirmed transactions with simple payment verification. The server can also lie by omission, and leave out a transaction that belongs to you. By default the client talks to about 10 servers. One of them, picked arbitrarily, is the main server. That one gets your address subscriptions, your history, and the broadcast. The others mostly get block headers and fee estimates. With auto-connect on, the fee estimate is a median of what those servers sent. With it off, you take the main server’s number. Either way the client applies a low and a high sanity limit. This attack is not a bad fee number. It is a substituted history entry, on the server that also takes the broadcast.
The advisory’s sequence is short. You broadcast tx1. A malicious main server swallows it. It updates your history with tx2. Tx2 conflicts with tx1 and pays the attacker. The signatures on tx2 are invalid. The wallet did not check them. The advisory says that is light client design. The client does not run a full script interpreter on mempool transactions. History shows tx2. Tx1 is not on the screen. If you then manually raise the fee on tx2, the wallet builds a replacement and you sign it. That signature is valid. It pays the attacker, and it pays a higher fee than the fake one showed.
The fake transaction did not have to reach a miner. User1 said tx1 never propagated on the Bitcoin peer-to-peer network, so the server held it. The row in the history tab was not a payment the network had. The bump is the first transaction you actually signed onto the attacker’s outputs.
Two reports, and the advisory is careful about which one lost money. On October 11, user1 sent a private note. After the broadcast, the history contained a different transaction. The fee-bump path was not clear yet. On October 18, Raju-K12 reported privately that they lost money after a fee bump. The advisory does not give an amount. I am not filling that in. Both reports said the attacker’s output address was made to match the last four characters of the address in tx1. Looking at the end of the address does not catch it. From the second report, tx2 carried a zero fee. The advisory says that was presumably so the user would bump it. Presumably is their word. I am leaving it there.
The advisory also says some servers are performing this attack in the wild. The advisory points at those two reports for that sentence. It is not a count of servers, and it is not a total of coins. I do not have either number, so I am not going to write one.
What the check still skips
The fix verifies the signatures on inputs the wallet owns, before an unconfirmed transaction is added to local history. That is the hole this attack used. Electrum’s own remark says the check stops at those inputs. Incoming unconfirmed transactions are still not validated. To check someone else’s inputs, the client would have to walk unconfirmed parent transactions until it hit one already in a block. Mined transactions already get SPV. The client still does not have a full consensus engine. An incoming unconfirmed payment can still be whatever the server said it was. An outgoing one, from coins the wallet owns, is what 4.8.3 now refuses to display if the signatures do not verify.
If you connect only to a server you trust, including one you run, the advisory says you are not affected. The bug is that trust in the server’s view of the mempool, not a flaw in the keys on the device. A public server is not the same choice as a server you operate. Running your own does not turn the history tab into a receipt. It means you picked who is allowed to describe unconfirmed transactions to you.
Without the upgrade, the workaround in the advisory is the same read you should do before any signature, fee bump or not. Check the output addresses and the amounts. The bump screen is a signing screen. It is not a notice that the payment you already broadcast is the one sitting in history.
Nunchuk’s post says the new builds do that local verify, and that no subscriber was hit by this bug or by the other one in the same release. The other one is the eMudhra intermediate keys. They refreshed the embedded certificate bundle and reject certificates that use the compromised intermediates, including the cross-signed ones. ONEKEY’s note says eight intermediate certificates were reported compromised on October 17, and the private keys were weak enough that anyone could forge a TLS certificate those intermediates would sign. https://www.onekey.com/resource/emudhra-ca-compromise-are-your-embedded-devices-at-risk. Neat’s advisory says Mozilla and the Chrome root program confirmed that on October 20. https://support.neat.no/article/security-advisory-october-2026-compromised-emudhra-intermediate-ca-certificates-affecting-neat-devices-and-cloud-services/. Browsers moved in a few days. A wallet ships its own bundle, so it does not move until the app does. I have not checked which earlier Nunchuk builds still trusted those intermediates. Their post says these builds reject them.
The broader line in the same post is separate, and it is also theirs. To date, they say, not a single Nunchuk subscriber has lost bitcoin from a Nunchuk-assisted multisig wallet. I have not audited that. Their closer says multisig works, and that a hot quorum is still a hot wallet. I am not arguing that paragraph. A second key does not inspect an Electrum server’s pending transaction unless the software checks it before anyone is asked to sign. Their post says this release rejects the invalid one before it can be offered as a fee-bump candidate. That matches the hole in the October 24 note. The bump is the payment. The row the server wrote into history was not.