Electrum 4.8.3 corrige une faille de substitution de transaction

Un serveur malveillant peut substituer une transaction dans Electrum

L'avis de sécurité GHSA-6jp4-8v48-cc5v, mis en ligne sur le dépôt GitHub d'Electrum le 24 octobre 2026 par SomberNight, attribue la gravité « High » (élevée) à une faille présente dans toutes les versions du client antérieures à la 4.8.3. La version 4.8.3 est indiquée comme corrigée.

Selon l'avis GHSA-6jp4-8v48-cc5v, le client Electrum fait confiance au serveur principal auquel il se connecte pour les transactions non confirmées, celles de la mempool (file d'attente des transactions pas encore minées). L'avis présente ce fonctionnement comme un « documented design » (choix de conception documenté, traduit de l'anglais).

Le scénario décrit par l'avis est le suivant : lorsque le client diffuse une transaction, nommée tx1, un serveur malveillant peut la conserver sans la relayer. Le serveur inscrit alors dans l'historique du portefeuille une transaction concurrente, tx2, dont les sorties renvoient vers une adresse de l'attaquant. Les signatures de tx2 sont invalides, mais un client léger comme Electrum ne les contrôle pas.

D'après l'avis, le portefeuille Electrum présente ensuite tx2 comme non confirmée et n'affiche plus tx1. Si l'utilisateur augmente à la main les frais de tx2 par RBF (« Replace-By-Fee », remplacement d'une transaction par une version mieux rémunérée), il signe cette transaction et paie l'attaquant.

Deux signalements d'utilisateurs attestent une exploitation réelle

L'avis d'Electrum affirme que certains serveurs mènent déjà cette attaque « in the wild » (en conditions réelles), sans préciser leur nombre ni leur identité. Le second utilisateur à l'avoir signalée, user2, a relevé les frais de tx2 et « lost money » (a perdu de l'argent, traduit de l'anglais) ; l'avis n'indique pas le montant perdu.

Le premier utilisateur, user1, a constaté selon l'avis que tx1 n'avait jamais circulé sur le réseau pair-à-pair Bitcoin, le serveur l'ayant gardée. Dans le cas de user2, le serveur avait fabriqué une tx2 sans frais, dans l'espoir présumé, selon l'avis, que la victime les relève.

Les deux utilisateurs ont rapporté que l'adresse de l'attaquant avait été calculée pour reproduire les quatre derniers caractères de l'adresse légitime de tx1.

La version 4.8.3 contrôle les signatures des entrées du portefeuille

Le correctif d'Electrum tient dans le commit 90fe308, intégré à la version 4.8.3. Selon l'avis, le client vérifie désormais les signatures des entrées qui dépensent des adresses du portefeuille (« is_mine ») pour les transactions de la mempool, avant de les ajouter à son historique local.

Le commit 90fe308 crée une erreur dédiée, accompagnée du message « Transaction has an invalid signature. » (la transaction porte une signature invalide), et retire de l'historique local les transactions dont la signature ne passe pas ce contrôle.

L'avis d'Electrum reconnaît une limite au correctif : seules les entrées appartenant au portefeuille sont validées, pas les transactions entrantes. Les développeurs l'expliquent par l'absence de moteur de consensus complet dans le client.

La chronologie publiée par Electrum débute le 11 octobre 2026, date d'une première alerte privée de user1, sans que le rôle de l'augmentation des frais soit alors compris. User2 (Raju-K12) a signalé sa perte le 18 octobre. La version 4.8.3 a été étiquetée dans git le 23 octobre, puis ses binaires et l'avis ont été rendus publics le 24 octobre. L'avis n'annonce aucune étape ultérieure.

Questions fréquentes

Quelles versions d'Electrum sont concernées par la faille GHSA-6jp4-8v48-cc5v ?

Selon l'avis GHSA-6jp4-8v48-cc5v publié sur GitHub le 24 octobre 2026, les versions d'Electrum antérieures à la 4.8.3 sont concernées. La version 4.8.3 est indiquée comme corrigée.

Comment un serveur malveillant peut-il piéger un utilisateur d'Electrum ?

Selon l'avis du 24 octobre 2026, le serveur garde la transaction diffusée (tx1) et inscrit à la place une transaction concurrente (tx2) vers l'adresse de l'attaquant. Si l'utilisateur augmente à la main les frais de tx2 par RBF, il la signe et paie l'attaquant.

Les utilisateurs d'Electrum qui se connectent à leur propre serveur sont-ils touchés par la faille ?

Non, selon l'avis GHSA-6jp4-8v48-cc5v du 24 octobre 2026 : les clients connectés à des serveurs de confiance, par exemple les leurs, ne sont pas affectés. Sans mise à jour, l'avis indique de vérifier adresses et montants de sortie avant toute signature.

Quelle limite le correctif d'Electrum 4.8.3 présente-t-il ?

Selon l'avis du 24 octobre 2026, même corrigé, le client ne valide que les entrées appartenant au portefeuille (« is_mine »), donc pas les transactions entrantes. L'avis explique que le client n'a pas de moteur de consensus complet ni d'interpréteur de scripts.

Quelle erreur affiche Electrum 4.8.3 face à une transaction à la signature invalide ?

Le commit 90fe308, intégré à la version 4.8.3 d'Electrum, ajoute une exception InvalidTxSignature dont le message est « Transaction has an invalid signature. » (la transaction porte une signature invalide, traduit de l'anglais).