Skip to content
Blockchain Posts

protocol

Electrum 4.8.3 corrige une faille de haute gravité exploitée via RBF

Electrum 4.8.3 corrige GHSA-6jp4-8v48-cc5v, une faille haute déjà exploitée : un serveur malveillant remplace une tx fraîchement diffusée par une fausse, piégeant l'utilisateur sur un RBF.

par 4 min de lecture
protocolbitcoinsecuriteelectrumoutil

Le portefeuille Electrum a publié le 24 octobre 2026 une mise à jour de sécurité en version 4.8.3 corrigeant GHSA-6jp4-8v48-cc5v, une vulnérabilité de gravité haute qui permet à un serveur Electrum malveillant de piéger un utilisateur lors d'un Replace-by-Fee (RBF) pour lui faire signer une transaction qui envoie ses bitcoins à l'attaquant. L'avis GitHub Security Advisory et l'article de bitcoin.fr confirment que l'attaque a déjà été exploitée dans la nature.

Mécanisme de l'attaque

Electrum fonctionne en client léger : il interroge un serveur Electrum pour l'état du mempool et la chaîne. Dans la version 4.8.2 et antérieures, le client ne vérifiait pas les signatures des entrées d'une transaction présente dans le mempool avant de l'afficher dans l'historique.

Un serveur malveillant pouvait donc :

  1. Intercepter la transaction fraîchement diffusée par l'utilisateur, sans la retransmettre au réseau.
  2. Renvoyer au client une transaction concurrente dépensant la ou les mêmes entrées, mais vers une adresse contrôlée par l'attaquant, avec des signatures invalides.
  3. L'utilisateur voyait sa transaction en attente, mais vers une mauvaise adresse. Un détail aggravant : dans les cas observés, les quatre derniers caractères de l'adresse attaquante correspondaient à ceux de l'adresse destinataire légitime — un piège visuel contre les utilisateurs qui ne vérifient que la fin d'une adresse.
  4. Si l'utilisateur tentait d'accélérer la confirmation via RBF, Electrum signait proprement la version frauduleuse avec sa clé privée — et là les signatures devenaient valides. L'attaquant recevait les fonds à la place du destinataire voulu.

Le correctif

Le commit 90fe308, inclus dans la 4.8.3, vérifie désormais les signatures sur les entrées « is_mine » d'une transaction du mempool avant de l'ajouter à l'historique du portefeuille. L'avis note une limite : les transactions entrantes ne sont toujours pas intégralement validées — la correction cible le cas d'exploitation documenté, pas la validation complète côté client.

- Version corrigée : 4.8.3
- Versions touchées : toutes les antérieures (< 4.8.3)
- Avis : GHSA-6jp4-8v48-cc5v
- CVE : aucun identifiant CVE attribué
- Commit de correction : 90fe308
- Gravité : haute (High)

Chronologie

L'avis GitHub, publié par SomberNight (mainteneur Electrum), détaille le calendrier :

  • 11 octobre 2026 : premier signalement privé par un utilisateur (crédité dannydeezy).
  • 18 octobre 2026 : second signalement, par un utilisateur (Raju-K12) qui a perdu des fonds sur un fee-bump malveillant.
  • 23 octobre 2026 : tag de la version 4.8.3 avec le correctif.
  • 24 octobre 2026 : publication des binaires 4.8.3 et divulgation publique.

Action immédiate pour les utilisateurs

  1. Mettre à jour vers 4.8.3 depuis electrum.org — toute version antérieure est vulnérable.
  2. Avant la mise à jour, ne pas accélérer une transaction en attente via RBF sans revérifier chaque octet de l'adresse de sortie et le montant dans la fenêtre de signature.
  3. Vérifier le serveur Electrum utilisé : les clients qui pointent sur un serveur auto-hébergé ou de confiance ne sont pas concernés par le vecteur, puisque l'attaque exige un serveur hostile.

Contexte

Electrum est maintenu depuis 2011 par Thomas Voegtlin et contributeurs. Son modèle client-serveur — client léger qui délègue l'état du mempool à un serveur distant choisi par l'utilisateur ou par défaut — a déjà subi plusieurs vagues de serveurs malveillants, notamment la campagne 2018-2019 qui exploitait un message d'erreur pour pousser des faux liens de téléchargement. La leçon est connue : tout ce qui vient d'un serveur Electrum doit être traité comme hostile jusqu'à vérification cryptographique. La 4.8.3 ferme un pan de surface qui n'avait pas encore été comblé.

L'épisode s'inscrit dans un trimestre chargé pour la sécurité des portefeuilles Bitcoin : la politique de divulgation de Bitcoin Core modifiée pour les failles trouvables par un LLM va dans le même sens — réduire la fenêtre entre découverte et patch pour les classes de bugs dont le coût de détection s'effondre.

Sources :

Articles liés