Les mainteneurs de bitcoinjs-lib, la bibliothèque JavaScript libre sur laquelle reposent de nombreuses applications Bitcoin pour construire et signer des transactions, ont révélé le 26 octobre deux bogues de gravité élevée dans la gestion des frais des PSBT : une transaction bitcoin partiellement signée (PSBT) forgée pouvait masquer ou minorer ses frais réels. Dans un test décrit dans le premier avis GitHub, une transaction qui versait 900 000 000 de satoshis (9 BTC) de frais était déclarée par la bibliothèque comme n’en payant que 200. Les versions corrigées sont sur npm depuis le 13 octobre. Aucune perte, aucune exploitation et aucun portefeuille touché n’ont été signalés.
Les deux avis ont été publiés sur GitHub à 18 h 40 UTC le lundi 26 octobre, classés « High » (élevé), au sein d’un lot de six. Aucun des deux bogues de frais n’a de numéro CVE. Les avis sur les frais désignent les versions 7.0.4, 6.1.9 et 5.2.2 comme versions corrigées. Un autre avis du lot, sur la vérification de la preuve de travail, n’est corrigé que dans les versions 7.0.5, 6.1.10 et 5.2.3, publiées plus tôt ce lundi-là : ce sont donc elles qui couvrent tous les avis touchant chaque branche de la bibliothèque.
La bibliothèque est très répandue. npm a compté 740 832 téléchargements sur la semaine du 20 au 26 octobre, et plusieurs dizaines de milliers de paquets npm la déclarent comme dépendance, souvent de façon indirecte ou pour de simples tests. Ce chiffre ne dit rien des applications réellement exposées, et ni les avis ni la presse n’en citent une à ce jour.
Deux bogues de bitcoinjs-lib qui font paraître les frais plus petits qu’ils ne sont
Les deux bogues se logent au même endroit : la façon dont la bibliothèque additionne la valeur des entrées d’une transaction. Les frais d’une transaction Bitcoin ne sont écrits nulle part : ils correspondent à ce que les entrées apportent moins ce que les sorties versent. Si la bibliothèque compte mal les entrées, son chiffre de frais est faux, et le garde-fou qui s’appuie dessus l’est aussi.
Enregistrements UTXO contradictoires : 9 BTC de frais affichés comme 200 satoshis
Le premier avis, GHSA-4mfv-5394-26c7, concerne une entrée de PSBT qui porte deux descriptions de la pièce qu’elle dépense : la transaction précédente complète (nonWitnessUtxo) et un court résumé de la sortie (witnessUtxo). Quand les deux divergent, le code de signature utilisait la transaction complète, alors que le calcul des frais reprenait le montant du résumé sans le vérifier.
La reproduction des mainteneurs, sur la version 7.0.1, utilise une entrée de 1 000 000 000 de satoshis dont le résumé annonce 100 000 200. Les frais réels sont de 900 000 000 de satoshis. getFee() renvoie 200. La signature est valide, et extractTransaction() rend la transaction terminée sans l’alerte sur le taux de frais qui aurait dû l’arrêter.
Selon l’avis, l’excédent devient des frais de mineur et ne revient pas, en soi, à celui qui a fabriqué la PSBT. La victime est le signataire, qui paie des frais très supérieurs à ceux que son application affichait.
Entrées sans enregistrement UTXO comptées pour zéro
Le second avis, GHSA-h52v-8xwg-7j95, vise les entrées finalisées qui ne portent aucun des deux enregistrements. La bibliothèque n’ajoutait tout simplement rien pour elles. Son exemple chiffré compte deux entrées de 10 000 et 90 000 satoshis, avec des données de montant seulement sur la première, et 9 000 satoshis de sorties. Les frais réels sont de 91 000 satoshis ; la bibliothèque en annonçait 1 000. Des frais excessifs pouvaient alors franchir le contrôle maximumFeeRate à l’extraction.
Cet avis insiste : le bogue ne crée aucune signature et ne dépense aucune pièce sans autorisation. L’argent n’est perdu que si une telle transaction est diffusée puis confirmée. CryptoSlate, qui a rapporté ces bogues le 28 octobre, trace la même ligne : sans transaction signée et valide acceptée par le réseau, personne ne perd rien.
Versions de bitcoinjs-lib touchées et corrigées
Les deux bogues de frais concernent trois branches de la bibliothèque. Le tableau ci-dessous reprend les plages d’après les avis et les heures de publication des correctifs sur npm, tous le 13 octobre 2026, selon le registre npm.
| Branche | Bogue des enregistrements contradictoires | Bogue des enregistrements manquants | Correctif des frais sur npm (13 oct., UTC) | Les six correctifs |
|---|---|---|---|---|
| 7.x | 7.0.0-rc.0 à 7.0.3 | 7.0.0-rc.0 à 7.0.3 | 7.0.4, 21 h 05 | 7.0.5 |
| 6.x | 6.0.0 à 6.1.8 | 6.0.0 à 6.1.8 | 6.1.9, 18 h 17 | 6.1.10 |
| 5.x | 5.2.0 à 5.2.1 | 5.1.0 à 5.2.1 | 5.2.2, 19 h 53 | 5.2.3 |
Les plages de la branche 6.x incluent la 6.1.0-rc.0. La version 7.0.5 a été publiée à 16 h 00 UTC le 26 octobre, la 6.1.10 à 15 h 41 et la 5.2.3 à 15 h 35, quelques heures avant la publication des avis. Les avis n’expliquent pas l’écart de 13 jours entre les premiers correctifs et la divulgation ; laisser aux utilisateurs le temps de mettre à jour avant de publier les détails est une pratique courante, mais aucune source ne dit que ce fut la raison ici.
Le commit de correction, signé du développeur landabaso, ajoute une routine commune que toute la bibliothèque utilise désormais pour retrouver la pièce dépensée par une entrée. Elle privilégie la transaction précédente complète, vérifie son hachage et l’index de sortie, et lève une erreur si un résumé est aussi présent avec une valeur ou un script différent. Le calcul des frais exige maintenant un montant pour chaque entrée et échoue dans le cas contraire. Les deux bogues ont été signalés par 0xaudron et Ali-Kalout ; junderw a relu le second correctif.
Quatre autres avis dans le même lot, dont un avec un CVE
Les quatre autres avis publiés le 26 octobre, eux aussi classés « High », n’ont aucun rapport avec les frais. Ils concernent les applications qui analysent ou vérifient des blocs, pas les portefeuilles ordinaires qui se contentent de signer.
- GHSA-8vv3-6qpc-gpw6 : des nœuds dupliqués dans le calcul de la racine de Merkle permettaient de faire passer pour valide une liste de transactions falsifiée. C’est le seul des six avis à porter un CVE, CVE-2026-107846, corrigé dans les versions 7.0.2, 6.1.8 et 5.2.1.
- GHSA-4vm8-79jj-j6w4 : la vérification de la preuve de travail acceptait des cibles compactes invalides (le champ nBits). Elle touche les versions de la 2.2.0 jusqu’aux 7.0.4, 6.1.9 et 5.2.2, est corrigée dans les 7.0.5, 6.1.10 et 5.2.3, et n’a aucun correctif pour les versions antérieures à la 5.0.0.
- GHSA-8247-5gp7-95qh et GHSA-88jr-9qj4-ccm4 : deux bogues de déni de service, l’un dû à des copies quadratiques dans
Block.fromBuffer, l’autre à des lectures d’entiers répétées, qui touchent uniquement les versions 7.0.0-rc.0 à 7.0.2 et sont corrigés dans la 7.0.3.
Une application en 7.0.4, 6.1.9 ou 5.2.2 dispose donc des deux correctifs de frais, mais pas encore de celui de la preuve de travail. La version 7.0.5 règle les six avis ; les 6.1.10 et 5.2.3 règlent tous ceux qui s’appliquent à leur branche, puisque les deux bogues de déni de service n’ont jamais touché les branches 5.x et 6.x.
Comment fonctionnent les frais d’une PSBT, et pourquoi le signataire doit vérifier les montants
Une PSBT, définie par le BIP 174, est une transaction qui circule entre plusieurs acteurs avant d’être complète : un coordinateur la construit, des cosignataires ou des appareils matériels ajoutent leurs signatures, puis quelqu’un la diffuse. La spécification elle-même présente un schéma multisignature 2-sur-3 et un coinjoin manuel, et précise que le format permet à des signataires hors ligne, comme les portefeuilles matériels, de signer sans accès direct à l’ensemble des pièces non dépensées. Notre guide pour comprendre le fonctionnement des transactions crypto explique entrées, sorties et frais depuis le début.
Le piège est qu’une PSBT ne prouve pas les montants qu’elle annonce. Les enregistrements d’entrée sont des données fournies par celui qui a construit le fichier. Un signataire prudent les compare aux vraies transactions précédentes avant de se fier à un chiffre de frais, et des bibliothèques comme bitcoinjs-lib proposent un garde-fou sur le taux de frais comme dernier rempart. Ces deux bogues ont trompé ce garde-fou, d’où l’avertissement des avis aux applications qui s’appuient sur getFee() ou sur le contrôle par défaut.
Qui est exposé aux bogues de frais des PSBT : la lecture de Coindaro
Ni les mainteneurs ni CryptoSlate n’ont dressé de liste d’applications exposées. D’après la lecture du texte des avis par Coindaro, l’exposition suppose trois conditions réunies : une application construite sur une version touchée, une PSBT venue d’un tiers (un cosignataire, un serveur coordinateur, une dApp), et une application qui se fie au chiffre de frais de la bibliothèque avant de signer et de diffuser. Le premier avis dit bien que l’exploitation exige que l’application accepte les données contradictoires et poursuive sans vérifier elle-même les pièces réelles ; le reste de cette section est notre interprétation.
Un portefeuille qui construit ses propres transactions à partir de données de pièces qu’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 a lui-même récupérées n’est pas, à notre avis, le cas que décrivent les avis. Si vous ne savez pas à quelle catégorie appartient votre outil, notre page sur les portefeuilles crypto et la garde des fonds présente les principaux types.
Rien à voir avec la faille d’Electrum sur les frais du 25 octobre
Le calendrier prête à confusion. Trois jours plus tôt, Coindaro a traité une autre faille liée aux frais dans Electrum, où un serveur malveillant masquait le vrai paiement en attente de l’utilisateur, dont la propre augmentation de frais signait alors un vol. Ce bogue a été exploité et au moins un utilisateur a perdu des fonds. Il se trouve dans Electrum, un portefeuille Python corrigé dans la version 4.8.3, et exige un serveur malveillant.
Les bogues de bitcoinjs-lib se trouvent dans une bibliothèque JavaScript, n’impliquent aucun serveur et n’ont aucune victime signalée. L’excédent de frais irait aux mineurs plutôt qu’à l’adresse d’un attaquant. Seul le mot « frais » relie les deux affaires.
Sécurité d’un portefeuille bitcoin : ce que doivent faire développeurs et utilisateurs
Pour les développeurs, les avis sur les frais demandent au minimum la 7.0.4, la 6.1.9 ou la 5.2.2. Passer directement à la 7.0.5, à la 6.1.10 ou à la 5.2.3 apporte en plus le correctif de la preuve de travail. Vérifiez aussi le fichier de verrouillage, car la bibliothèque arrive souvent par l’intermédiaire d’un autre paquet. Si vous ne pouvez pas mettre à jour, vérifiez vous-même les sorties référencées et rejetez toute PSBT dont les deux enregistrements UTXO divergent. Désactiver les contrôles de frais n’est pas une solution de contournement, ajoutent les mainteneurs.
Les utilisateurs de portefeuilles ne peuvent pas corriger une bibliothèque eux-mêmes. Ils peuvent en revanche mettre leurs applications à jour et, lorsqu’une PSBT vient d’un tiers, regarder quelles pièces sont dépensées et ce que vaut chacune, plutôt que la seule ligne des frais, avant d’approuver. Des frais qui paraissent beaucoup trop faibles pour la taille du paiement méritent un second regard. Le portefeuille avec lequel vous signez n’est jamais plus prudent que les données qu’il contrôle.
Aucune autorité européenne ne s’est exprimée sur ces avis, et on ne relève à ce stade aucune déclaration de l’AMF. Les prestataires de l’Union qui gèrent des portefeuilles pour des clients sous MiCA et qui s’appuient sur des outils JavaScript sont dans la même situation que tout le monde : le remède est une mise à jour.
Ce que l’on ignore encore des avis sur bitcoinjs-lib
Aucune application n’a été citée comme touchée, ni par les mainteneurs ni par CryptoSlate. Aucune exploitation dans la nature n’a été décrite. Les auteurs des signalements ne sont connus que par leurs pseudonymes GitHub, et les deux bogues de frais n’ont pour l’instant pas de numéro CVE. La suite à surveiller : les projets de portefeuilles et de multisignature qui dépendent de bitcoinjs-lib publieront-ils leurs propres communiqués sur les versions qu’ils ont livrées ?