https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 28 Oct 2026 22:36:44 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-117601 <p>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&#39;s transaction and display an invalid zero-fee copy paying an attacker address, tricking users into RBF fee-bumping and signing it.</p> <p>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&#39;s transaction and display an invalid zero-fee copy paying an attacker address, tricking users into RBF fee-bumping and signing it.</p> https://db.gcve.eu/vuln/fkie_cve-2026-117601 https://db.gcve.eu/vuln/ghsa-6jp4-8v48-cc5v <p><strong>Affected:</strong> PyPI: electrum</p> <p>### Summary</p> <p>The main Electrum server the client connects to is trusted with mempool (&#34;unconfirmed&#34;) transactions. This is documented [design](https://electrum.readthedocs.io/en/latest/faq.html#does-electrum-trust-servers). [0]</p> <p>However now someone figured out a way to practically exploit it: - when the client broadcasts a new tx1, a malicious server can swallow it, - and update the client&#39;s history with a conflicting (invalid) tx2 that replaces the outputs with the attacker&#39;s output address. - Tx2 has invalid signatures, but this is not checked (due to light client design). - The wallet will display tx2 as an unconfirmed transaction - tx1 will not be displayed. - If the client then manually RBF fee-bumps tx2, the client will sign it with a higher fee, and hence pay the attacker.</p> <p>### Fixes</p> <p>Commit 90fe30822 contains the fix [1], included in version 4.8.3. The client now verifies the signatures of `wallet.is_mine` inputs for mempool txs (before adding them to its local history).</p> <p>Users should upgrade (and regularly do so in any case). As a workaround, without upgrading, when signing any transaction, for bumping the fee or not, they should verify the output addresses and amounts are as expected.</p> <p>Clients that connect to servers they trust (e.g. run their own) are not affected.</p> <p>### Remarks</p> <p>- some servers are performing this attack in the wild - electrum received two user-reports of this. user1 noticed after broadcasting tx1 the wallet history contained a different tx. user2…</p> <p><strong>Affected:</strong> PyPI: electrum</p> <p>### Summary</p> <p>The main Electrum server the client connects to is trusted with mempool (&#34;unconfirmed&#34;) transactions. This is documented [design](https://electrum.readthedocs.io/en/latest/faq.html#does-electrum-trust-servers). [0]</p> <p>However now someone figured out a way to practically exploit it: - when the client broadcasts a new tx1, a malicious server can swallow it, - and update the client&#39;s history with a conflicting (invalid) tx2 that replaces the outputs with the attacker&#39;s output address. - Tx2 has invalid signatures, but this is not checked (due to light client design). - The wallet will display tx2 as an unconfirmed transaction - tx1 will not be displayed. - If the client then manually RBF fee-bumps tx2, the client will sign it with a higher fee, and hence pay the attacker.</p> <p>### Fixes</p> <p>Commit 90fe30822 contains the fix [1], included in version 4.8.3. The client now verifies the signatures of `wallet.is_mine` inputs for mempool txs (before adding them to its local history).</p> <p>Users should upgrade (and regularly do so in any case). As a workaround, without upgrading, when signing any transaction, for bumping the fee or not, they should verify the output addresses and amounts are as expected.</p> <p>Clients that connect to servers they trust (e.g. run their own) are not affected.</p> <p>### Remarks</p> <p>- some servers are performing this attack in the wild - electrum received two user-reports of this. user1 noticed after broadcasting tx1 the wallet history contained a different tx. user2…</p> https://db.gcve.eu/vuln/ghsa-6jp4-8v48-cc5v