Electrum EUVD-2026-110851

Exploitation requires a rogue local process already running on the victim's machine as the same OS user, with filesystem write access to the Electrum data directory - specifically the ability to write a plugin into the plugins/ folder and to set that plugin 'enabled' in the user-owned 0600 config file. Only Electrum 4.6.0 through 4.7.1 are affected, because the external plugin system that contains the flawed two-step loader was introduced in 4.6.0. The root cause is that the step-1 __init__.py load checked only the config 'enabled' flag and not the plugin-password ECDSA signature (step 2 did validate the signature). Limiting factors: there is no remote vector (AV:L) and the attack presupposes a prior local compromise at the user's privilege level; it is not exploitable against a host where the attacker lacks local user-level write access to the data directory.

This is a locally-exploitable authorization bypass (CVSS 4.0 8.6, High), and the exploitability signals pull in opposite directions from the impact signals. The CVSS vector is AV:L/AC:L/AT:N/PR:N/UI:N: no user interaction and no Electrum-level authentication, but AV:L means the attacker must already be executing code on the victim's machine. Per the GHSA threat model, exploitation presupposes a rogue local process running as the victim's user with write access to the Electrum data directory - i.e. the host is already partially compromised - so this is a local privilege/trust-boundary escalation into the Electrum process, not a remote attack. Impact is high (VC/VI/VA:H): arbitrary code execution inside a Bitcoin wallet process, which can mean key/seed theft and fund loss. On the exploitation side the signals are quiet: there is no CISA KEV listing, no EPSS score supplied, and no public PoC or exploit reference among the inputs (references are vendor advisory, two patch commits, and the VulnCheck write-up). The vendor/vuln.today decision label is this_week, consistent with a serious-but-locally-gated flaw that should be remediated promptly rather than as an emergency. Net: a genuine priority for high-value or multi-user/shared hosts because of the wallet-theft impact, but the local-access precondition sharply limits real-world mass exploitation compared to the raw score. Note PR:N here reflects that no Electrum authentication is required, not that no foothold is required - the AV:L and the described need for filesystem write access are the true gate.

An attacker who has already achieved low-privilege code execution as the victim's user (e.g. via a separate malware dropper or a compromised unrelated process) drops a malicious plugin into Electrum's plugins/ folder and flips its 'enabled' flag in the 0600 config file. The next time Electrum starts, the loader executes the plugin's __init__.py without verifying the plugin-password ECDSA signature, giving the attacker arbitrary code execution inside the wallet process and access to wallet operations. No public exploit identified at time of analysis, but the mechanism is fully documented in the vendor GHSA and the fix commit.