24 октября проект Electrum выпустил сборки 4.8.3 и опубликовал advisory GHSA-6jp4-8v48-cc5v (высокая серьёзность). Речь об атаке, которую некоторые публичные Electrum-серверы уже проводят против пользователей.
Как работает атака
Electrum — лёгкий клиент: подтверждённые транзакции он проверяет через SPV, а неподтверждённым из мемпула доверяет серверу. Это задокументированная особенность, но теперь её научились эксплуатировать:
- пользователь отправляет транзакцию tx1, а вредоносный сервер не передаёт её в сеть;
- вместо неё сервер добавляет в историю кошелька конфликтующую tx2 с теми же входами, но с выходом на адрес атакующего; подписи у tx2 недействительны, но клиент их не проверял;
- адрес атакующего подобран так, чтобы последние четыре символа совпадали с настоящим;
- tx2 идёт с нулевой комиссией — расчёт на то, что пользователь «ускорит» зависший платёж через RBF. При повышении комиссии кошелёк подписывает tx2 заново — и деньги уходят атакующему.
Разработчики получили два сообщения: первый пользователь заметил подмену 11 октября, второй 18 октября сообщил о потере средств после повышения комиссии.
Что исправлено
Начиная с 4.8.3 клиент проверяет подписи входов, принадлежащих кошельку, прежде чем добавить неподтверждённую транзакцию в историю. Входящие платежи с чужих адресов по-прежнему не проверяются — для этого клиенту нужен полноценный движок валидации.
Что делать
- Обновиться до 4.8.3, скачивая сборки только с официального сайта и проверяя подпись.
- Если обновиться нельзя — перед любой подписью, включая повышение комиссии, сверять адреса и суммы выходов.
- Тех, кто подключается к собственному или доверенному серверу, атака не затрагивает.
On October 24 the Electrum project shipped 4.8.3 binaries and published advisory GHSA-6jp4-8v48-cc5v (high severity). It describes an attack that some public Electrum servers are already running against users.
How the attack works
Electrum is a light client: it verifies confirmed transactions via SPV but trusts the server for unconfirmed mempool transactions. That is documented behaviour, but someone has now found a practical way to abuse it:
- the user broadcasts tx1, and the malicious server never relays it to the network;
- instead the server adds a conflicting tx2 to the wallet history, spending the same inputs but paying the attacker’s address; tx2’s signatures are invalid, but the client did not check them;
- the attacker’s address is ground so its last four characters match the legitimate one;
- tx2 carries a zero fee, betting that the user will “speed up” the stuck payment with RBF. Bumping the fee makes the wallet re-sign tx2, and the money goes to the attacker.
The developers received two reports: one user noticed the swap on October 11, and a second reported on October 18 that they lost funds after bumping the fee.
What was fixed
From 4.8.3 the client verifies signatures on the wallet’s own inputs before adding an unconfirmed transaction to its history. Incoming payments from other addresses are still not validated — that would require a full validation engine in the client.
What to do
- Upgrade to 4.8.3, downloading only from the official site and verifying the signature.
- If you cannot upgrade, check output addresses and amounts before signing anything, including fee bumps.
- Users connecting to their own or another trusted server are not affected.