CVE-2026-117601 in Electrum
Summary
by MITRE • 10/27/2026
Electrum before 4.8.3 fails to verify signatures of wallet-owned inputs in unconfirmed mempool transactions, allowing malicious servers to replace a just-broadcast transaction with a conflicting one. Attackers can swallow the user's transaction and display an invalid zero-fee copy paying an attacker address, tricking users into RBF fee-bumping and signing it.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in versions of Electrum prior to 4.8.3 represents a critical failure in signature verification logic for unconfirmed transactions within the mempool. Specifically, the wallet client did not adequately verify signatures associated with inputs owned by the user when processing transactions that had been broadcast but were still pending confirmation. This oversight creates a window of opportunity where malicious Electrum servers can manipulate transaction propagation and display states to deceive users into authorizing unintended financial transfers. The core technical flaw lies in the application's handling of Replace-By-Fee (RBF) mechanisms, which are designed to allow senders to increase fees for stuck transactions but were exploited here due to insufficient validation checks on conflicting inputs during the mempool phase.
In a typical scenario involving this vulnerability, an attacker operating a malicious Electrum server intercepts or influences the transaction flow of a user who has just broadcasted a legitimate payment. The server can then present a conflicting version of that same transaction to the client interface. This fraudulent copy is constructed with zero fees and directs funds to an address controlled by the attacker rather than the intended recipient. Because the wallet fails to properly verify the signatures on these unconfirmed mempool inputs, it may accept this invalid state as valid or at least fail to immediately reject the conflicting proposal based on signature integrity alone. This manipulation tricks the user into believing their original transaction is stuck due to low fees, prompting them to initiate an RBF fee bumping process.
The operational impact of this flaw is severe financial loss for end users who fall victim to such social engineering attacks facilitated by technical deception. When a user attempts to speed up their transaction via RBF, they are effectively signing the conflicting transaction presented by the malicious server. By doing so, the attacker successfully swallows the original legitimate transaction and replaces it with one that pays the attacker's address instead of the intended merchant or recipient. This constitutes a direct theft of funds through exploitation of client-side trust assumptions regarding mempool consistency and signature verification integrity. The attack relies heavily on the user's lack of visibility into the underlying cryptographic validation processes, making them susceptible to interface-based manipulation rather than pure protocol-level exploits.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application failed to correctly validate input data related to transaction signatures in specific contexts. It also relates to CWE-345 Insufficient Verification of Data Authenticity, since the wallet did not sufficiently verify that the displayed transaction state accurately reflected the cryptographically signed intent of the user before allowing further actions like fee bumping. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is consistent with techniques involving T1074 Data Staged or more specifically aspects of client-side manipulation where an adversary alters data in transit to achieve unauthorized access or theft. The exploitation vector primarily involves Network Communication and potentially Social Engineering if the user interface design does not clearly distinguish between original and replacement transactions.
Mitigation for this issue requires immediate updates to all instances of Electrum running versions older than 4.8.3, as these have been patched to enforce strict signature verification on wallet-owned inputs even within unconfirmed mempool contexts. Users should ensure their software is updated from official channels to prevent exposure to malicious servers that might attempt such manipulations. Additionally, security best practices suggest enabling transaction confirmation notifications and verifying the destination address and fee details manually before signing any RBF or replacement transactions. Organizations relying on Electrum for treasury management should implement monitoring tools that detect unusual mempool activity or conflicting transaction proposals from connected nodes. Maintaining up-to-date software is the primary defense against this class of vulnerabilities, as developers have addressed the logic gaps in signature verification routines to ensure that only cryptographically valid and intended transactions are processed by the wallet interface.