Electrum 4.8.3: Malicious Servers Swapped Transactions, RBF Trap

Electrum 4.8.3, released on 24 October 2026, fixes a high severity flaw (GHSA-6jp4-8v48-cc5v) that malicious Electrum servers are exploiting in the wild. A server could hide a payment you just broadcast, show you a fake one paying the attacker, and wait for you to bump its fee. Every version before 4.8.3 is affected. Upgrade, and verify outputs before signing anything.

This is not a break in Bitcoin's cryptography. It is a trust boundary problem in a light client: the wallet believed a remote server about unconfirmed transactions, and the server lied. That makes it a useful case study for anyone who thinks about software supply chains, because the same question applies to every package mirror, registry proxy and metadata feed you consume. Which upstream do you let tell you what is true, and what do you check yourself?

What happened

Electrum is one of the oldest open source Bitcoin wallets. It is a "light" client: rather than downloading and validating the whole blockchain, it connects to Electrum servers, asks them about the addresses in your wallet, and checks confirmed transactions against block headers with Simple Payment Verification (SPV). Unconfirmed transactions are different. Electrum's own FAQ has long said that servers are trusted about unconfirmed transactions and that a server "can lie by omission".

According to the advisory the maintainers published on GitHub, someone found a practical way to turn that trust into theft. The advisory says plainly that "some servers are performing this attack in the wild". Two users reported it privately. The first saw a different transaction in their history right after broadcasting. The second bumped the fee on the fake transaction and lost money. Neither the advisory nor the press coverage we read gives an amount.

The fix shipped as Electrum 4.8.3. The release notes call it a security update and list the issue as "(sev-high)". There is no CVE ID for this issue as of 25 October 2026, and the GitHub advisory carries no CVSS score.

Timeline

Times are UTC where a primary source gives one.

How the attack works, in plain language

You do not need to understand Bitcoin script to follow this. Think of three parties: you, the Electrum server your wallet talks to, and the Bitcoin network (the thousands of nodes that relay and mine transactions).

1. You create and sign a payment, call it tx1, and press Broadcast. Electrum hands tx1 to the server it is connected to and asks it to relay the transaction to the network.
2. A malicious server simply does not relay it. In User1's case the advisory says tx1 never appeared on the Bitcoin peer to peer network.
3. The server then tells your wallet about a different transaction, tx2. In the Electrum protocol, the server answers history queries with a list that ends in mempool entries (height 0, or -1 when some inputs are themselves unconfirmed), and the wallet then fetches the raw transactions it is told about. It spends exactly the same coins as tx1, but its outputs send almost everything to an address the attacker controls.
4. tx2 cannot be valid, because the attacker does not have your keys. Its signatures are copied from tx1 and do not match the new outputs. Before 4.8.3, Electrum did not check signatures on unconfirmed transactions it learned about from the server, so it accepted tx2 into your history anyway.
5. Because tx2 conflicts with tx1 (they spend the same coins), Electrum shows tx2 as your pending payment and stops showing tx1.
6. tx2 was built with essentially zero fee, so it looks stuck. If you then use Electrum's fee bump feature, which relies on replace by fee (RBF), the wallet builds a new version of tx2 with a higher fee and signs it with your real keys. That signed replacement is a perfectly valid transaction paying the attacker.

The theft happens at step 6, and only if you take that step. The server cannot steal on its own. It needs you to sign something new, and it shapes the situation so that signing feels like the natural fix for a stuck payment.

Why the fee bump is the trap

Fee bumping is ordinary. Bitcoin fees move with demand, and replace by fee was designed so a sender can raise the fee on a transaction that is sitting in the mempool. BIP125, the specification for opt in RBF, lets a transaction be replaced by one spending at least one of the same inputs if it pays a higher absolute fee than the original and meets the node's minimum relay fee rate. Electrum's FAQ says it marks transactions as replaceable by default, and tells users to right click a transaction in History and choose "Increase Fee".

That is the subtle part. When you bump a fee, you are not re-approving your original payment. You are approving a brand new transaction whose outputs are copied from whatever the wallet currently believes your pending transaction is. If the wallet's belief came from a liar, so do the outputs you sign.

User1's report in the advisory makes this concrete. They used a 2 of 3 multisig wallet with two Trezor hardware wallets and verified the outputs on both devices before broadcasting. That verification did its job: the 62 signatures in tx1 all verify against the real transaction and none verify against the fake. But a hardware wallet check protects the transaction you are signing at that moment. It cannot protect a later fee bump if you approve that second signature without reading its outputs on the device screen again.

Why "check the last four characters" failed

Both reports say the attacker's address was ground to match the last four characters of the real destination. In User1's case, both addresses ended in ...GyQ3. Generating an address with a chosen short suffix is cheap. Four characters is not verification; it is a coincidence an attacker can manufacture in advance. The same lesson shows up in software supply chains whenever a human compares a short fragment of a hash, a commit ID or a package name and treats a match as proof.

Why the fake looked so convincing

The advisory reproduces User1's analysis of the fake transaction. It had the same inputs, version and locktime as the real one. All 31 inputs carried scriptSigs that were byte for byte identical to the real transaction's. It had two outputs instead of one: nearly everything went to the lookalike address, and a small amount went to an address the wallet itself had used before, which would make the transaction look partly familiar. The outputs added up to roughly the full input value, so the fee was about zero. The history entry first showed the full amount as unconfirmed to an unknown address and later changed to "Local". User1's real transaction, per the advisory, remained valid and unbroadcast.

Technical details

Everything in this section comes from the Electrum advisory, the fix commit, the release notes, the electrum.org download page, Electrum's own source at the 4.8.3 tag, or public package indexes, as named.

Advisory record

Affected and fixed versions

The advisory does not list any other Electrum forks or rebranded wallets. If you run software derived from the Electrum codebase, ask its maintainers whether the same history handling exists there. We found no statement from forks either way.

What the fix changes

The fix is commit 90fe308 (full hash 90fe30822561e515a9d2d6e5a352cc07780999eb), titled "Merge "verify_sigs": adb: check sigs of is_mine txins of unconf txs". Per the GitHub API it touches seven files, adding 446 lines and removing 13:

In summary, based on reading the diff:

• AddressSynchronizer gains a verify_txins callback. The wallet supplies _verify_txin_signatures, which rebuilds the scriptSig and witness for each input the wallet owns and checks them against the signatures and public keys.
• When a new unconfirmed transaction spends the wallet's coins, add_transaction calls _are_new_inputs_valid. If the signatures do not check out, it raises a new exception, InvalidTxSignature, defined in electrum/util.py.
• Transactions the server claims are mined are held in a _held_txs set until they are verified, with helpers _add_held_tx, is_held_tx and clear_held_txs.
• In synchronizer.py, the history callback catches InvalidTxSignature and skips that transaction without disconnecting from the server. Held transactions are cleared when the wallet resets to a different server.

Residual limitations the maintainers state

The advisory is candid about what the fix does not cover:

• Only inputs that spend the wallet's own coins (is_mine inputs) are checked.
• Incoming transactions, where the inputs belong to someone else, are still not signature checked.
• Electrum has no full consensus engine or script interpreter. Checking other people's inputs would mean recursively validating unconfirmed parent transactions until reaching mined ones.
• Mined transactions are still verified with SPV, as before.

In practice: after 4.8.3, a server can no longer forge an outgoing payment from your coins in your history. It can still lie about unconfirmed incoming payments, or omit transactions, as the FAQ has always said. Treat an unconfirmed incoming payment as unconfirmed.

Other security work in 4.8.3

The release notes credit four reporters for security fixes: dannydeezy, tokenistq, Raju-K12 and Amadeus29. Only the server swap issue has a published advisory. Other changes in the notes that a security reviewer may care about:

• Rich text string rendering disabled by default in the GUIs.
• Stricter validation of plugin metadata, and zip plugins now load from the bytes whose signature was verified.
• Stricter BOLT11 invoice parsing, stricter BIP32 child index parsing, and descriptors reject trailing characters.
• A DNSSEC KSK-2024 root trust anchor added, plus DNSSEC fixes.
• Network requests no longer go through the Qt library.
• certifi and pip bumped to distrust the revoked eMudhra/emSign certificate, which ties back to the eMudhra CA key compromise.
• Android build moved from Java 17 to 21 and dropped androidx dependencies.
• A new dscancel command (double spend cancel) in the CLI.

Release signatures and signers

The electrum.org download page says the executables are reproducible and that the current release has been signed by ThomasV, SomberNight, Emzy, felixb_f321x and svanstaa. Every artifact has a detached .asc signature next to it, for example Electrum-4.8.3.tar.gz.asc and electrum-4.8.3.dmg.asc. The public keys live in the pubkeys/ directory of the Electrum repository. Running gpg --show-keys on three of those key files on 25 October gave:

The download page itself tells users to check a key's fingerprint against independent sources. Do that rather than trusting this table alone.

Homebrew's cask for Electrum lists version 4.8.3 with the dmg SHA-256 27d73fba5dcc0f46f14849e965a93fb720833d7fdf002dabe13b127d6d7ff67f. That is the hash Homebrew pins; the GPG signature on electrum.org remains the authoritative check.

Indicators

The advisory publishes no server hostnames, IP addresses or attacker addresses beyond the ...GyQ3 suffix shared by User1's real and fake destinations, and that suffix is a property of one victim's payment, not a general indicator. None of the press reports we read added any. Behavioral signs are more useful than indicators here:

• An outgoing transaction appears in history that you did not create, often to an address you do not recognise, sometimes with a second small output to one of your own used addresses.
• The transaction shows a fee of about zero.
• The transaction you actually signed disappears from history.
• The entry later flips from unconfirmed to "Local".
• A block explorer you trust, or your own node, has never seen the transaction ID the wallet shows.

Package index status on 25 October

Distribution packages will move on their own schedules. Check again before you rely on a distro build.

Earlier Electrum advisories, for context

None of the earlier advisories involved a server forging wallet history. They are listed so you can see that the project publishes advisories with clear version ranges, which makes inventory work easier.

Who is affected

Organisations hold Bitcoin in more places than many security teams realise: treasury desks, finance teams, developer test wallets, and research or incident response machines used to trace payments. If any of those run Electrum, they are in scope.

What changed since the first reports

• Exploitation status. The advisory states some servers are performing the attack. PANews attributes the same statement to Electrum's post on X. Nobody has published how many servers were involved.
• Victim count. All sources agree on two private reports, one with a loss. Bitcoin.com News refers to "two private reports" and confirms one loss. No amount has been disclosed.
• Release date. The git tag and the release notes say 23 October; the binaries and the advisory went public on 24 October. Press used 24 October.
• Scope wording. Some coverage paraphrased the "not affected" group loosely. The advisory says clients connected to servers they trust, such as their own, are not affected. It does not vouch for any particular operator's public servers. We follow the advisory.
• Other wallets. One wallet company told Cryptonomist that its users are unaffected unless they manually chose a compromised server, and that it is adding client side validation using the same approach as Electrum. We have not verified that independently.

What to do now

1. Find every Electrum install

Linux:

# Packaged installs
dpkg -s electrum 2>/dev/null | grep -i '^Version'
rpm -q electrum 2>/dev/null
flatpak info org.electrum.electrum 2>/dev/null | grep -i version

# AppImages and tarballs in home directories
find / -xdev \( -iname 'electrum-*.AppImage' -o -iname 'Electrum-*.tar.gz' -o -name 'run_electrum' \) 2>/dev/null

# Version reported by the binary on PATH
electrum --version

macOS:

defaults read /Applications/Electrum.app/Contents/Info.plist CFBundleShortVersionString
brew info --cask electrum 2>/dev/null | head -3
mdfind "kMDItemCFBundleIdentifier == '*electrum*'"

Windows (PowerShell):

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, `
  HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*, `
  HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Where-Object { $_.DisplayName -like '*Electrum*' } |
  Select-Object DisplayName, DisplayVersion, InstallLocation

# Portable builds are not registered; search for them
Get-ChildItem -Path C:\Users -Recurse -Filter 'electrum-*-portable.exe' -ErrorAction SilentlyContinue

Android: open Settings, then Apps, then Electrum, and read the version. For managed fleets, your mobile device management console should report the installed version.

Containers and source repositories:

# Look for Electrum pinned in build files
grep -rniE 'electrum[-_ ]?(==|@|:)?[0-9]+\.[0-9]+\.[0-9]+' \
  --include=Dockerfile --include='*.yml' --include='*.yaml' \
  --include='*.txt' --include='*.toml' --include='*.nix' .

# Inside a running container
docker exec <container> sh -c 'grep -m1 ELECTRUM_VERSION /usr/lib/python3*/*-packages/electrum/version.py 2>/dev/null'

Electrum's version string lives in electrum/version.py as ELECTRUM_VERSION. At the 4.8.3 tag it reads '4.8.3'.

2. Download 4.8.3 and verify it

Use only electrum.org, as both the site and the FAQ instruct. For the Python tarball, the site's own steps are:

wget https://download.electrum.org/4.8.3/Electrum-4.8.3.tar.gz
wget https://download.electrum.org/4.8.3/Electrum-4.8.3.tar.gz.asc
wget https://raw.githubusercontent.com/spesmilo/electrum/master/pubkeys/ThomasV.asc
gpg --show-keys ThomasV.asc      # compare the fingerprint with an independent source
gpg --import ThomasV.asc
gpg --verify Electrum-4.8.3.tar.gz.asc Electrum-4.8.3.tar.gz

The same pattern applies to the dmg, the Windows installers, the AppImage and the APKs, each of which has a matching .asc file. Because several builders sign each release, import more than one signer's key if you want gpg to report more than one good signature.

3. Review your server settings

Electrum stores its configuration as JSON. On Linux and macOS the default location is ~/.electrum/config; on Windows it is under %APPDATA%\Electrum\config. The relevant keys, defined in simple_config.py, are server, oneserver and auto_connect (which defaults to true).

jq '{server, oneserver, auto_connect}' ~/.electrum/config

The command line options at the 4.8.3 tag include -s / --server to choose a server and -1 / --oneserver to stay on that one server. If you run your own Electrum server backed by your own Bitcoin node, pointing your wallet at it with one server mode removes the third party from the trust path. That is the setup the advisory describes as not affected.

4. Check recent history

1. After upgrading, open each wallet and look at outgoing transactions from the past weeks.
2. For any transaction that showed as stuck or "Local", look up its transaction ID on your own node or a block explorer you trust.
3. If the wallet showed a payment you never made, or a payment you made never reached the network, do not sign a fee bump. Contact Electrum through the channels on electrum.org and keep the wallet files and logs.
4. If you already bumped a fee, compare the outputs of the confirmed transaction with the address you meant to pay, character by character or by scanning the intended address again from its source.

5. Until you can upgrade

The advisory's workaround is short: when signing any transaction, whether you are bumping fees or not, verify that the output addresses and amounts are what you expect. On a hardware wallet, read every output on the device screen for every signature, including the fee bump. Compare full addresses, not the last few characters.

Open questions

• How many servers, and who runs them? Not published. Anyone can run an Electrum server and many public ones exist, so a list may never be complete.
• How much was lost? Not disclosed by the maintainers or the reporting user.
• Are forks and derivative wallets affected? Not stated. Any client that accepts unconfirmed history from a server without checking signatures on its own inputs has the same shape of problem.
• Will a CVE be assigned? None as of 25 October. GitHub advisories can receive a CVE later; check the advisory page.
• When will distributions ship 4.8.3? Debian and Flathub had not caught up when we checked.

What would have helped

Practices any team can use

Decide what each upstream is trusted for, in writing. Electrum documented that servers are trusted for unconfirmed transactions. The gap was that the wallet then let that unverified data feed a signing flow. In software supply chains, a registry proxy or mirror is often trusted for package metadata, and the same mistake happens when metadata from an unverified source decides what gets built and signed. Write down which inputs are verified (signatures, hashes, provenance) and which are merely believed, and keep the believed ones away from irreversible actions.

Verify locally anything you are about to sign. The 4.8.3 fix does exactly this: before a transaction spending your coins enters history, the wallet checks the signatures it can check. The supply chain equivalent is verifying a package's signature or hash before it enters a build, rather than trusting that the mirror served the right bytes.

Treat the second approval as a new approval. The fee bump was a second signature on data the user did not choose. Code review has the same failure mode: a reviewer approves a pull request, then a later force push, rebase or automated "fix" changes what actually ships. Require re-approval when the content changes.

Compare whole identifiers. Four characters were ground to match. Compare full addresses, full hashes and full package names. Use tooling for the comparison when you can.

Run your own upstream for high value flows. Users on their own server were not affected. For build systems, the equivalent is a private, verified mirror for critical dependencies, fed only from sources whose signatures you check.

Keep an inventory of desktop software that touches money or keys. Wallets often arrive outside the normal software request process, installed by one person for one task. An inventory query that answers "where is Electrum, and what version" in minutes is worth more than a perfect one that takes a week. The SBOM incident response guide covers the same idea for code.

Verify release signatures as part of installation. Electrum signs every artifact and publishes the keys. Make gpg --verify part of your install script or image build, so a tampered download fails the build rather than reaching a laptop. The tensorlake npm compromise post makes the same argument for provenance on package registries.

Rebuild quickly when a fix lands. Images, VM templates and golden laptop builds that bundle a vulnerable version will keep reintroducing it until they are rebuilt.

Where Safeguard fits

Electrum is mostly a desktop and phone application. Safeguard does not inspect wallet history, watch Electrum servers, monitor endpoints for installed apps, or judge whether a transaction is genuine. It would not have prevented this attack and it does not replace the advisory's advice to read outputs before signing. Where it can help is with the parts of the problem that look like any other software inventory and patching job:

• Finding where a component lives. SBOM and dependency scanning covers repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version. If you build images or tooling that bundle Electrum, scan them and look for the component. The GitHub advisory leaves the ecosystem field empty and the PyPI name is a placeholder, so whether any scanner automatically matches this advisory to your component is not guaranteed. Verify the version yourself rather than relying on an automatic match.
• Keeping old versions out. Policies and gates evaluated in the platform can block a build or image that carries a version you have decided is no longer allowed.
• Doing the fix work with approval. The Safeguard CLI assistant can edit code and run commands with your approval, for example bumping a pinned Electrum version in a Dockerfile, adding a gpg --verify step, rebuilding and running tests. Its /permissions modes range from Ask to Strict. Autonomous remediation can open fix pull requests; it ships switched off.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Electrum is distributed as signed application builds from electrum.org rather than through a package registry, and this issue was found by users who reported it to the maintainers. We make no claim that Zero-Day Discovery would have surfaced it.

Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API. It is keyed mainly on CVEs and open source packages. This issue has no CVE, so the Electrum advisory and release notes are the source of truth here.

The habit that applies is the one this incident rewards: take signed components from a source you have chosen to trust, verify them, and rebuild fast when a fix lands.

Common mistakes

• Bumping the fee to "fix" a stuck payment without reading the outputs. This is the exact step the attack depends on.
• Trusting the hardware wallet check from the first signature. It covered that signature only.
• Matching the last few characters of an address. The attacker ground them to match.
• Assuming the distro package is current. On 25 October, every Debian suite we checked carried an affected version.
• Downloading from a mirror or search ad. Electrum's site says to download only from electrum.org and to verify GPG signatures.
• Assuming 4.8.3 makes all unconfirmed data trustworthy. It checks your own inputs only. Incoming unconfirmed payments are still not signature checked.
• Forgetting images and templates. Rebuild any VM image, container or laptop build that bundles Electrum, or the old version comes back.
• Treating "no CVE" as "not serious". The maintainers rated it High and say it is being exploited.

FAQ

Which Electrum version fixes the server transaction swap?

Electrum 4.8.3. The GitHub advisory lists every version below 4.8.3 as affected and 4.8.3 as patched. The release notes date the release 23 October 2026; the binaries and advisory went public on 24 October.

Is this being exploited?

Yes, according to the maintainers. The advisory says some servers are performing the attack in the wild. Two users reported it privately and one lost funds after bumping the fee on the fake transaction. No amount or server list has been published.

Can a malicious server steal my bitcoin without me doing anything?

Not with this technique, based on the advisory. The fake transaction has invalid signatures and cannot confirm on its own. The theft requires the user to sign a fee bump on the fake transaction, which produces a valid replacement paying the attacker.

Does a hardware wallet protect me?

Partly. It ensures the transaction you approve is the one that gets signed. User1's Trezor approved transaction was never broadcast, but its signatures were valid only for the real payment. A fee bump is a new transaction, so you must read its outputs on the device too.

Does 4.8.3 close the whole class of problem?

No, and the maintainers say so. 4.8.3 verifies signatures on unconfirmed transactions that spend your own coins. It does not verify incoming unconfirmed transactions, because Electrum has no full script interpreter. A server can still lie about incoming payments or omit transactions until they confirm.

Is there a CVE or CVSS score?

Not as of 25 October 2026. The GitHub advisory is rated High and carries no CVSS vector. Use GHSA-6jp4-8v48-cc5v as the identifier.

Am I safe if I run my own Electrum server?

The advisory says clients connected to servers they trust, such as their own, are not affected by this attack. You still need to upgrade for the other 4.8.3 fixes, and your server is only as trustworthy as the node behind it.

How do I verify the 4.8.3 download?

Download the artifact and its .asc file from electrum.org, import a signer's key from the repository's pubkeys/ directory, check that key's fingerprint against an independent source, and run gpg --verify. The current release lists five signers.

Are Electrum servers themselves vulnerable?

The advisory is about the wallet client trusting server data. The fix is entirely client side. Server software is not described as vulnerable; the problem is servers run by attackers.

Why does this belong on a supply chain blog?

Because the failure is about trust in an upstream. The wallet accepted unverified data from a source it could not control and fed it into a signing step. Build pipelines do the same thing with mirrors, proxies and metadata feeds. The fix is the same shape in both places: verify locally whatever leads to a signature or a release.

For Electrum the upstream fix exists, so the job is getting 4.8.3 onto every machine and out of every old image. The general pattern for the open source dependencies and images you build yourself follows.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json, and runs install and tests with approval. For Electrum, you would point the same loop at a repository that builds an image or laptop bundle and ask it to move the pinned Electrum version to 4.8.3 and add a gpg --verify step, approving each edit and the rebuild. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The runner demo shows setting up the Safeguard runner on your own machine, approving it with its device code, and scanning from the terminal. Here, that is how you would scan the images and build directories on a treasury or ops workstation without sending them anywhere first, then check the output for any Electrum component older than 4.8.3.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For this incident, the folder would hold your image or provisioning scripts, and you would approve the version bump and the signature check one step at a time. Approving each step is the same discipline the advisory asks of anyone signing a fee bump.

Click through it at your own pace, or open it full screen.

To scan the images and repositories you build, download Safeguard and follow the CLI docs. For the rest of the month, see October 2026 security incidents and what would have helped, and for a general plan when a component you depend on turns hostile, the compromised dependency incident response playbook.

Quick check

Sources

• GitHub advisory GHSA-6jp4-8v48-cc5v: Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it
• GitHub REST API record for GHSA-6jp4-8v48-cc5v
• Electrum security advisories list
• Fix commit 90fe30822561e515a9d2d6e5a352cc07780999eb
• Git tag object for 4.8.3 (GitHub API)
• Electrum RELEASE-NOTES
• Electrum version.py at 4.8.3
• Electrum commands.py at 4.8.3 (command line options)
• Electrum simple_config.py at 4.8.3
• Electrum signing keys (pubkeys directory)
• Electrum download page
• Electrum FAQ: Does Electrum trust servers?
• Electrum command line documentation
• Electrum protocol methods
• BIP125: Opt-in Full Replace-by-Fee Signaling
• Debian sources: electrum package versions
• Homebrew cask: electrum
• Flathub: org.electrum.electrum
• PyPI JSON API: electrum
• Cryptonomist: Electrum wallet security flaw (24 October 2026)
• The Defiant: Electrum patches wallet flaw exploited through malicious servers
• Bitcoin.com News: Electrum wallet attack hid bitcoin theft behind a fee increase
• PANews: coverage of the Electrum 4.8.3 security update (25 October 2026)

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.