Portefeuille Electrum : la 4.8.3 corrige la faille qui faisait du bouton des frais un vol de bitcoins

Le portefeuille Electrum a publié la version 4.8.3 pour corriger une faille qui permettait à un serveur malveillant de masquer un paiement que l’utilisateur venait d’envoyer et d’en afficher à la place un faux, en tous points semblable. Quand l’utilisateur appuyait ensuite sur le bouton pour augmenter les frais, le vrai portefeuille signait le vol. Le développeur d’Electrum SomberNight a révélé le problème dans un avis de sécurité GitHub publié le 24 octobre 2026 à 12 h 52 UTC et classé « High » (gravité élevée). blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il y écrit que « certains serveurs mènent cette attaque dans la nature ». Au moins un utilisateur a perdu des fonds. Ni l’avis ni les articles parus jusqu’ici ne donnent de montant, de nombre de victimes ou de nom de serveur.

Toutes les versions d’Electrum antérieures à la 4.8.3 sont concernées. La version a été étiquetée le 23 octobre, selon les notes de version du projet, et les binaires ont été diffusés avec la divulgation publique le 24 octobre. Aucun numéro CVE n’a été attribué.

Cette histoire ne contient ni logiciel malveillant ni fausse mise à jour, la méthode des grands vols visant Electrum entre 2018 et 2020. L’attaque de 2026 fonctionne contre le portefeuille authentique, non modifié. Elle suppose deux choses : la confiance qu’Electrum accorde à son serveur pour les paiements qui ne sont pas encore dans un bloc, et un utilisateur qui veut qu’un paiement bloqué passe plus vite.

Electrum croyait son serveur sur parole pour les paiements non confirmés

Electrum est un client léger. Il ne télécharge pas la blockchain de bitcoin. Il se connecte à un serveur, qui lui indique quelles transactions concernent les adresses du portefeuille. Pour les transactions déjà incluses dans un bloc, le portefeuille vérifie ce qu’on lui dit à l’aide des en-têtes de blocs, une méthode appelée vérification simplifiée de paiement (SPV) ; l’avis note que les transactions minées étaient déjà contrôlées ainsi. Les paiements encore en attente d’un bloc ne l’étaient pas.

Les transactions non confirmées se trouvent dans la mempool, la salle d’attente des paiements que les mineurs n’ont pas encore retenus. Pour celles-ci, Electrum s’en remettait au récit du serveur. L’avis décrit ce choix comme un élément documenté de la conception, et non comme un bogue glissé par erreur. Le bogue tenait à ce que cette confiance autorisait une fois combinée à une autre fonction.

Cette fonction, c’est le Replace-by-Fee, ou RBF. Un paiement envoyé avec des frais trop faibles peut rester bloqué des heures. Le RBF permet à l’expéditeur de diffuser une nouvelle version du même paiement avec des frais plus élevés, qui remplace l’ancienne dans les files des mineurs. Electrum la propose sous forme d’augmentation des frais sur tout paiement sortant en attente. Notre guide sur le trajet d’une transaction crypto du portefeuille au bloc détaille les frais et la mempool.

Comment fonctionne l’échange, étape par étape

Le titre même de l’avis résume le schéma : « Un serveur malveillant peut remplacer une transaction tout juste diffusée et tenter d’amener l’utilisateur à la remplacer par RBF » (en anglais dans l’original). Dans l’ordre, d’après le mécanisme décrit par l’avis :

1. L’utilisateur envoie des bitcoins depuis Electrum. Le portefeuille signe le paiement et le diffuse.
2. Un serveur malveillant avale ce vrai paiement : il ne le transmet jamais au réseau bitcoin et cesse de le signaler au portefeuille.
3. Le serveur fournit au portefeuille une autre transaction, qui dépense les mêmes pièces mais paie l’attaquant. Cette transaction fabriquée est invalide, car l’attaquant ne peut pas produire les signatures de l’utilisateur.
4. Avant la 4.8.3, Electrum ne vérifiait jamais les signatures des transactions non confirmées. Il affichait le faux paiement dans l’historique comme une transaction en attente ordinaire et cachait le vrai.
5. L’utilisateur voit ce qui ressemble à un paiement coincé dans la file et demande au portefeuille d’augmenter les frais.
6. Pour construire l’augmentation, le portefeuille part de la transaction fabriquée et signe une nouvelle version avec des frais plus élevés. Cette version porte de vraies signatures, paie l’attaquant et est valide sur le réseau.

Tout repose sur la dernière étape. La transaction fabriquée ne déplace rien à elle seule, puisque n’importe quel nœud bitcoin la rejetterait. C’est la signature de l’utilisateur sur l’augmentation des frais qui transforme le brouillon de l’attaquant en paiement accepté par le réseau.

Du côté de l’utilisateur, rien ne paraît cassé. Le portefeuille est le vrai Electrum, téléchargé depuis le vrai site. L’historique montre un paiement sortant, à peu près du montant attendu, toujours en attente. Appuyer sur le bouton des frais est le remède habituel dans cette situation.

L’avis publie les notes d’incident du premier rapporteur, et elles montrent à quel point l’échange était convaincant. Le portefeuille était un multisig 2 sur 3 protégé par deux portefeuilles matériels Trezor, et dépensait 31 entrées vers une seule sortie. L’utilisateur a contrôlé la sortie sur les deux Trezor, puis diffusé. L’historique a alors affiché le montant total, non confirmé, vers une adresse inconnue. Le faux reprenait les mêmes entrées et les mêmes données de signature que le vrai paiement, mais aucune de ses 62 signatures ne lui correspondait. Il versait presque tout à l’adresse sosie, renvoyait une petite somme vers l’une des adresses du portefeuille et laissait des frais proches de zéro. Le vrai paiement n’est jamais arrivé dans la mempool, et cet utilisateur n’a pas augmenté les frais.

Des frais nuls et une adresse qui finit pareil

Les fausses transactions étaient conçues pour être « boostées ». Dans le second rapport, celui qui s’est soldé par une perte, le serveur a fabriqué le faux avec des frais nuls, « vraisemblablement dans l’espoir que l’utilisateur augmente ses frais », écrit l’avis. Un paiement sans frais ne se confirme pas, ce qui donne à celui qui surveille son historique une bonne raison d’agir.

Elles étaient aussi conçues pour résister à un coup d’œil. Les deux rapporteurs ont indiqué que l’adresse de l’attaquant avait été « meulée », c’est-à-dire générée par essais successifs, jusqu’à ce que ses quatre derniers caractères correspondent à ceux de l’adresse qu’ils voulaient payer, selon l’avis. Dans le premier cas, les deux finissaient par GyQ3. Celui qui ne contrôle que la fin y voit une correspondance. Notre guide sur les formats d’adresses crypto et les erreurs à éviter explique pourquoi toute la chaîne compte.

Du premier signalement privé du 11 octobre au correctif du 24 octobre

Deux personnes ont signalé le problème en privé en octobre, à une semaine d’intervalle, et la seconde avait déjà perdu de l’argent, d’après l’avis.

Les deux signalements étaient privés, et l’avis en est la seule trace publique. Celui du 18 octobre est la plus ancienne perte connue. L’avis ne dit pas quand les serveurs hostiles ont commencé, combien ils étaient, ni si les deux rapporteurs s’y étaient connectés par la liste publique de serveurs d’Electrum.

Ce que change la 4.8.3 : les signatures sont vérifiées avant l’affichage d’un paiement en attente

Le correctif se trouve dans le commit 90fe308, la fusion d’une branche nommée verify_sigs, écrite par SomberNight. Il touche sept fichiers, avec 446 lignes ajoutées et 13 supprimées.

Pour les transactions encore dans la mempool, Electrum vérifie désormais les signatures ECDSA de chaque entrée appartenant au portefeuille avant d’ajouter la transaction à l’historique. Le contrôle gère les portefeuilles multisig, où l’ordre des signatures compte, ainsi que les anciennes données scriptSig et les données témoin SegWit. Une transaction qui échoue déclenche une erreur InvalidTxSignature et est supprimée.

Le résultat est limité, mais il ferme la brèche. Un serveur hostile peut toujours cacher un paiement. Il ne peut plus en inventer un qui dépense les pièces de l’utilisateur, car le portefeuille repérera que les signatures manquent ou sont fausses : il ne reste donc plus de modèle falsifié à faire signer par une augmentation des frais.

Le texte de SomberNight est franc sur ce que le contrôle ne couvre pas. Seules les entrées alimentées par les adresses du portefeuille sont vérifiées, si bien que les paiements entrants ne sont pas validés de cette façon. Les couvrir obligerait à contrôler une à une les transactions parentes non confirmées jusqu’à une transaction minée, et le client n’a pas d’interpréteur de scripts complet pour le faire, dit l’avis. Dans le code, le plugin watchtower, qui ne détient aucune clé, saute la vérification. Un paiement en attente vers le portefeuille reste donc, jusqu’à sa confirmation, ce que le serveur rapporte et rien de plus.

Chaque version d’Electrum de 2026 est étiquetée mise à jour de sécurité

Les notes de version classent la 4.8.3 comme mise à jour de sécurité, avec des correctifs pour des signalements de quatre personnes, dont les deux à l’origine du cas des frais. Elle ajoute aussi mempool.space comme source de taux de change, intègre la clé racine DNSSEC dite KSK-2024, introduit une commande dscancel pour annuler un paiement en le dépensant à nouveau, et ajoute des contrôles sur les HTLC Lightning entrants. Un changement remonte à 2018 : les interfaces graphiques désactivent désormais par défaut l’affichage en texte enrichi. Ce n’est pas un correctif isolé. Les trois versions 4.8 précédentes portent la même étiquette, tout comme les 4.7.0, 4.7.1 et 4.7.2, publiées entre le 22 janvier et le 1er avril.

Celui qui a installé la 4.8.0 en juillet et s’en est tenu là a trois versions de sécurité de retard.

Wallet Electrum : peut-on l’utiliser sans risque maintenant ?

Avec la 4.8.3, la voie du paiement falsifié décrite dans l’avis est fermée pour les paiements envoyés par l’utilisateur. Les anciennes versions restent exposées dès qu’elles dialoguent avec un serveur que l’utilisateur ne contrôle pas. Les gestes pratiques viennent de l’avis et de la page de téléchargement d’Electrum :

• Passer à Electrum 4.8.3, téléchargé uniquement sur electrum.org. La page de téléchargement demande de n’utiliser aucune autre source, fournit des signatures, et précise que les binaires sont reproductibles et signés par plusieurs compilateurs. Vérifier la signature GPG avant l’installation.
• Ignorer quiconque propose son aide par message privé. La même page indique qu’Electrum n’offre pas d’assistance privée aux utilisateurs et que de tels aidants sont très probablement des imposteurs.
• Tant que la mise à jour n’est pas faite, lire l’adresse de destination en entier et le montant avant de signer toute transaction, augmentation des frais ou annulation comprises. Les quatre derniers caractères ne suffisent pas : c’est précisément ce que les attaquants ont imité.
• Se méfier d’un paiement en attente qui affiche des frais nuls, ou qui semble inviter à augmenter les frais. Comparer son adresse à celle qu’on voulait payer avant d’y toucher.
• Connecter Electrum à son propre serveur ou à un serveur de confiance. L’avis dit que de tels clients ne sont pas exposés.

Un portefeuille matériel ne dispense pas de regarder. Une augmentation des frais du paiement falsifié doit tout de même être signée sur l’appareil, qui affiche la destination ; le cas du premier rapporteur montre que le sosie partagerait sa fin avec la vraie adresse. Avec un portefeuille sur son propre ordinateur, ces contrôles reviennent à l’utilisateur, contrepartie habituelle de l’auto-conservation.

Qui n’était pas exposé : les portefeuilles sur serveurs de confiance

L’avis désigne un groupe hors d’atteinte : les portefeuilles connectés à des serveurs que leurs propriétaires jugent fiables, par exemple un serveur qu’ils font tourner eux-mêmes. L’attaque exige un serveur hostile à l’autre bout de la connexion.

Ce que l’avis ne dit pas

C’est une affaire de sécurité, pas encore une affaire de pertes. Les faits connus s’arrêtent à une victime confirmée, un pseudonyme GitHub et une somme non précisée. Aucun total n’a été publié, ni par l’avis ni par Bitcoin.com News, The Cryptonomist ou TokenPost.

Aucune adresse d’attaquant ou de victime, aucun identifiant de transaction ni nom de serveur n’a non plus été rendu public. Sans eux, personne en dehors de l’affaire ne peut suivre les bitcoins volés sur un explorateur de blocs, et tout chiffre de perte serait une supposition. Restent ouvertes les questions du montant dérobé, du nombre de victimes, de l’identité et du nombre de serveurs malveillants, de l’usage de serveurs publics par les rapporteurs et de la date de début des attaques.

Serveurs Electrum hostiles de 2018 à 2020 : les vols par fausse mise à jour

Des serveurs malveillants ont déjà visé les utilisateurs d’Electrum, avec une autre arme. À partir de fin décembre 2018, des attaquants ont fait tourner de nombreux serveurs piégés dont les messages d’erreur, affichés en texte formaté par les versions d’Electrum antérieures à la 3.3.3, enjoignaient d’installer une mise à jour urgente. Le lien menait à de fausses pages GitHub et à un cheval de Troie à la place du portefeuille.

Decrypt rappelait que 202 BTC, soit environ 2,3 millions de dollars à l’époque, avaient été déclarés volés lors des premières attaques de décembre 2018. Au 16 avril 2019, Malwarebytes Labs comptait plus de 771 BTC volés dans cette campagne, environ 4 millions de dollars alors, et nommait les variantes OSX.ElectrumStealer et Electrum.Stealer.

En mars et avril 2019, les développeurs d’Electrum ont exploité une faille de déni de service des anciens clients pour chasser des serveurs publics les versions antérieures à la 3.3, afin qu’elles ne reçoivent plus les faux messages. Les attaquants ont répliqué avec un botnet qui inondait les serveurs légitimes pour pousser les vieux clients vers les serveurs piégés. The Hacker News rapportait le 30 avril 2019 que le botnet, baptisé ElectrumDoSMiner, tournait sur plus de 152 000 machines infectées selon Malwarebytes, que les vols atteignaient 4,6 millions de dollars et que les utilisateurs étaient invités à passer à la 3.3.4.

La campagne est revenue en 2020. Fin août, un utilisateur affirmait sur GitHub avoir perdu 1 400 BTC ; un autre en déclarait 36,5 le lendemain. ZDNet a ensuite fait état de plus de 25 millions de dollars volés, et environ 1 980 BTC, soit à peu près 22,9 millions de dollars, dormaient dans des portefeuilles liés aux attaquants, selon Decrypt le 12 octobre 2020. Le développeur d’Electrum Thomas Voegtlin a déclaré au média : « Une enquête de police est en cours en Allemagne et au Royaume-Uni. »

Les montants en dollars sont ceux rapportés à l’époque, non convertis au cours actuel du bitcoin.

Même serveur hostile, autre ruse

Les deux épisodes partent du même point : un serveur qui ment au portefeuille. De 2018 à 2020, le mensonge était un message, et le vol exigeait que la victime remplace Electrum par un logiciel malveillant. En 2026, le mensonge est une transaction, et c’est le vrai portefeuille qui signe le vol. Il n’y a aucun fichier à télécharger, donc rien à repérer pour un antivirus. Sur une ancienne version, la seule défense est la lecture de l’adresse par l’utilisateur avant de signer.

Comme l’explique notre guide sur les endroits où se produisent vraiment les piratages crypto, la chaîne elle-même est rarement le maillon faible ; ce sont les portefeuilles et ceux qui s’en servent. La même semaine, Bitcoin Core a changé sa façon de divulguer les bogues, en abandonnant son embargo d’un an pour les failles qu’une IA peut trouver avec une seule requête.

Au 25 octobre, l’avis ne mentionne aucun nom de serveur ni identifiant de transaction. Si les développeurs ou les deux rapporteurs les publient, l’ampleur du vol pourra enfin être mesurée sur la chaîne.