Falha na Electrum deixava servidor malicioso roubar seu Bitcoin enquanto você acelerava a taxa

Um servidor malicioso conseguia redirecionar seu Bitcoin para seu próprio endereço enquanto você tentava apenas acelerar uma operação pendente. A Electrum corrigiu essa falha grave na versão 4.8.3, lançada em 24 de outubro de 2026. Dois usuários relataram o ataque antes da correção, e pelo menos um perdeu fundos de fato.

Electrum 4.8.3: qual foi a brecha de segurança

O RBF (Replace-By-Fee) é um recurso do Bitcoin que permite substituir uma transação ainda não confirmada por outra com taxa mais alta, para destravar um pagamento parado na fila da mempool quando a rede está congestionada. É uma função comum e, até agora, considerada segura dentro de carteiras como a Electrum.

A falha corrigida na 4.8.3 estava na validação desse recurso. Segundo a TFTC, versões anteriores exigiam verificação de assinatura apenas para operações já confirmadas. Para pagamentos pendentes, essa verificação não era feita da mesma forma. Isso abria uma janela para um servidor malicioso — aqueles que a carteira consulta para montar e transmitir transações — apresentar ao usuário um "aumento de taxa" que, na prática, redirecionava os fundos para o endereço do atacante.

Do ponto de vista de quem usa o app, a tela parecia normal: uma solicitação de bump de taxa comum. Por isso o golpe passava despercebido.

Os dois casos que vieram à tona

De acordo com o Bitcoin.com News, dois relatos públicos antecederam a correção:

• 11 de outubro de 2026: o usuário dannydeezy relatou que sua transação havia sido substituída sem autorização. O relato não confirma perda efetiva de fundos nesse caso.
• 18 de outubro de 2026: o usuário Raju-K12 perdeu fundos depois de aprovar o que acreditava ser um aumento de taxa, sem notar que a operação redirecionava para o atacante.

A falha afeta todas as versões da Electrum lançadas antes da 4.8.3, independentemente de sistema operacional.

Como se proteger agora: passo a passo

1. Verifique a versão instalada. Abra a Electrum, vá em "Ajuda" (ou "Help") e confira o número. Qualquer coisa anterior à 4.8.3 está vulnerável.

2. Baixe a atualização só do canal oficial. Pegue o instalador na página oficial (electrum.org) ou no repositório oficial no GitHub. Não use links de terceiros, fóruns ou buscadores — prática obrigatória para carteiras de custódia própria.

3. Confira a assinatura do arquivo antes de instalar. A Electrum assina seus binários com uma chave GPG divulgada no próprio site. Verificar essa assinatura confirma que o arquivo não foi adulterado.

4. Feche a versão antiga e instale a 4.8.3. No Windows e Linux, rode o instalador sobre a instalação existente; no macOS, substitua o aplicativo na pasta Applications. Reabra e confirme em "Ajuda" que a versão mudou.

5. Troque de servidor se usa um público. A equipe da Electrum recomenda, segundo a TFTC, usar apenas servidores próprios ou de confiança comprovada. Se você conecta sua carteira a um servidor ElectrumX ou Fulcrum público e desconhecido, essa é a porta de entrada do ataque. Quem tem um nó Bitcoin Core próprio pode rodar seu próprio backend (Fulcrum é uma opção usada) e apontar a Electrum para "localhost" em Configurações de Rede.

6. Revise manualmente qualquer aumento de taxa pendente, do início ao fim do endereço. Antes de confirmar um bump de RBF, confira o endereço de destino exibido na tela de confirmação caractere por caractere, do primeiro ao último. Segundo o Bitcoin.com News, os endereços fraudulentos usados nesse ataque foram montados para reproduzir propositalmente os últimos caracteres do endereço legítimo — então conferir só o começo ou o final do endereço não é suficiente. Se o valor ou o destinatário mudou em relação ao pagamento original, cancele e investigue.

7. Não assine nada às pressas. O golpe se aproveitou exatamente da urgência de quem só queria destravar um pagamento parado. Se uma operação está demorando, vale esperar ou usar uma ferramenta de cálculo de taxa (como mempool.space) antes de agir.

O que observar depois de atualizar

Servidor público continua sendo o maior risco. Mesmo com a 4.8.3 instalada, depender de servidores de terceiros não confiáveis é o vetor que permitiu o ataque. Rodar seu próprio backend reduz drasticamente essa exposição.

Backups de seed não resolvem isso. O problema não estava na chave privada, mas na operação exibida pela interface. Ter a seed guardada não teria evitado as perdas no caso relatado.

Outras carteiras leves merecem o mesmo cuidado. O princípio vale para qualquer carteira que não rode um full node: sempre que o software depende de um terceiro para montar a transação, existe espaço para manipulação se a verificação do lado do cliente for fraca.

A atualização é gratuita e leva poucos minutos. Não há custo além do tempo de baixar, verificar assinatura e reiniciar. É o único passo que efetivamente fecha a brecha corrigida na 4.8.3.