I responsabili di bitcoinjs-lib, la libreria JavaScript open source che molte app Bitcoin usano per costruire e firmare le transazioni, hanno reso pubblici 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 26 ottobre due bug di gravità alta nella gestione delle PSBT: una transazione bitcoin parzialmente firmata (PSBT) costruita ad arte poteva nascondere o ridurre la propria commissione reale. In un test descritto nel primo avviso su GitHub, una transazione che versava 900.000.000 satoshi (9 BTC) di commissioni veniva indicata dalla libreria come una da 200 satoshi. Le versioni corrette sono su npm dal 13 ottobre. Non risultano perdite, sfruttamenti in corso né portafogli colpiti.
Entrambi gli avvisi sono stati pubblicati su GitHub alle 18:40 UTC di lunedì 26 ottobre, con gravità alta, in un lotto di sei. Nessuno dei due bug sulle commissioni ha un numero CVE. Gli avvisi indicano come versioni corrette la 7.0.4, la 6.1.9 e la 5.2.2. Un altro avviso del lotto, sul controllo della proof of work, è risolto soltanto nella 7.0.5, nella 6.1.10 e nella 5.2.3, uscite poche ore prima nella stessa giornata di lunedì: sono quindi le versioni che coprono tutti gli avvisi relativi a ciascuna linea di rilascio.
La libreria è molto diffusa. Secondo npm ha totalizzato 740.832 download nella settimana dal 20 al 26 ottobre, e decine di migliaia di pacchetti npm la elencano tra le dipendenze, in molti casi in modo indiretto o solo per i test. Il dato non dice però quali app siano esposte, e né gli avvisi né la stampa finora ne citano una.
Due bug di bitcoinjs-lib fanno apparire la commissione più bassa di quanto sia
Entrambi i bug stanno nel modo in cui la libreria somma il valore degli input di una transazione. La commissione di una transazione Bitcoin non è scritta da nessuna parte: è ciò che gli input apportano meno ciò che gli output pagano. Se la libreria conta male gli input, la sua cifra sulla commissione è sbagliata, e lo è anche il controllo di sicurezza che si basa su di essa.
Record UTXO in conflitto: 9 BTC di commissioni mostrati come 200 satoshi
Il primo avviso, GHSA-4mfv-5394-26c7, riguarda un input di PSBT che porta due descrizioni della moneta che spende: la transazione precedente completa (nonWitnessUtxo) e un breve riepilogo dell’output (witnessUtxo). Quando i due non coincidono, il codice di firma usava la transazione completa, mentre il calcolo della commissione prendeva l’importo dal riepilogo senza verificarlo.
La riproduzione dei manutentori sulla versione 7.0.1 usa un input da 1.000.000.000 di satoshi il cui riepilogo ne dichiara 100.000.200. La commissione reale è di 900.000.000 di satoshi. getFee() restituisce 200. La firma risulta valida e extractTransaction() restituisce la transazione finita senza l’avviso sul tasso di commissione che avrebbe dovuto fermarla.
L’avviso precisa che l’eccedenza diventa commissione per i miner e non va, di per sé, a chi ha costruito la PSBT. La vittima è chi firma, che paga una commissione molto più alta di quella mostrata dall’app.
Input senza record UTXO contati come zero
Il secondo avviso, GHSA-h52v-8xwg-7j95, riguarda gli input finalizzati che non portano nessuno dei due record. La libreria non aggiungeva semplicemente nulla per loro. L’esempio dell’avviso ha due input da 10.000 e 90.000 satoshi, con i dati sull’importo solo per il primo, e 9.000 satoshi di output. La commissione vera è di 91.000 satoshi; la libreria ne riportava 1.000. Una commissione eccessiva poteva così superare il controllo maximumFeeRate in fase di estrazione.
Questo avviso sottolinea che il bug non crea firme e non sposta monete senza autorizzazione. Il denaro si perde soltanto se una transazione del genere viene trasmessa e confermata. CryptoSlate, che ha dato la notizia il 28 ottobre, traccia lo stesso confine: senza una transazione firmata e valida accettata dalla rete, nessuno perde nulla.
Versioni di bitcoinjs-lib colpite e corrette
I due bug sulle commissioni toccano tre linee di rilascio. La tabella riporta gli intervalli indicati negli avvisi e gli orari di pubblicazione delle correzioni, tutte il 13 ottobre 2026, secondo il registro npm.
| Linea di rilascio | Bug dei record in conflitto | Bug dei record mancanti | Correzione sulle commissioni su npm (13 ott, UTC) | Tutte e sei le correzioni |
|---|---|---|---|---|
| 7.x | da 7.0.0-rc.0 a 7.0.3 | da 7.0.0-rc.0 a 7.0.3 | 7.0.4, 21:05 | 7.0.5 |
| 6.x | da 6.0.0 a 6.1.8 | da 6.0.0 a 6.1.8 | 6.1.9, 18:17 | 6.1.10 |
| 5.x | da 5.2.0 a 5.2.1 | da 5.1.0 a 5.2.1 | 5.2.2, 19:53 | 5.2.3 |
Gli intervalli della 6.x comprendono la 6.1.0-rc.0. La versione 7.0.5 è stata pubblicata alle 16:00 UTC del 26 ottobre, la 6.1.10 alle 15:41 e la 5.2.3 alle 15:35, poche ore prima che gli avvisi diventassero pubblici. Lo scarto di 13 giorni tra le prime correzioni e la divulgazione non è spiegato negli avvisi; dare agli utenti il tempo di aggiornare prima di rivelare i dettagli è una pratica comune, ma nessuna fonte dice che il motivo sia stato questo.
Il commit della correzione, dello sviluppatore landabaso, introduce una routine unica che ora tutta la libreria usa per trovare la moneta spesa da un input. Dà la precedenza alla transazione precedente completa, ne controlla l’hash e l’indice dell’output, e genera un errore se è presente anche un record di riepilogo con valore o script diverso. Il calcolo della commissione richiede ora un importo per ogni input e fallisce in caso contrario. Entrambi i bug sono stati segnalati da 0xaudron e Ali-Kalout; junderw ha rivisto la seconda correzione.
Altri quattro avvisi nello stesso lotto, uno con un CVE
Gli altri quattro avvisi pubblicati il 26 ottobre, anch’essi di gravità alta, non c’entrano con le commissioni. Contano per le app che leggono o verificano i blocchi, non per i comuni portafogli che si limitano a firmare.
- GHSA-8vv3-6qpc-gpw6: nodi duplicati nel calcolo della radice di Merkle permettono di far passare per valido un elenco falso di transazioni. È l’unico dei sei ad avere un CVE, CVE-2026-107846, ed è stato corretto nella 7.0.2, nella 6.1.8 e nella 5.2.1.
- GHSA-4vm8-79jj-j6w4: il controllo della proof of work accettava target compatti non validi (il campo nBits). Riguarda le versioni dalla 2.2.0 fino alla 7.0.4, alla 6.1.9 e alla 5.2.2, è corretto nella 7.0.5, nella 6.1.10 e nella 5.2.3, e non ha correzione per le versioni precedenti la 5.0.0.
- GHSA-8247-5gp7-95qh e GHSA-88jr-9qj4-ccm4: due bug di negazione del servizio, uno dovuto alla copia quadratica in
Block.fromBuffere uno alle letture ripetute di interi, che interessano solo dalla 7.0.0-rc.0 alla 7.0.2 e sono corretti nella 7.0.3.
Un’app ferma alla 7.0.4, alla 6.1.9 o alla 5.2.2 ha quindi le due correzioni sulle commissioni ma non quella sulla proof of work. La 7.0.5 chiude tutti e sei gli avvisi; la 6.1.10 e la 5.2.3 chiudono tutti quelli che riguardano la propria linea, dato che i due bug di negazione del servizio non hanno mai toccato la 5.x né la 6.x.
Come funzionano le commissioni di una PSBT e perché chi firma deve controllare gli importi
Una PSBT, definita nella BIP 174, è una transazione che passa tra più parti prima di essere completa: un coordinatore la costruisce, i cofirmatari o i dispositivi hardware aggiungono le firme, e alla fine qualcuno la trasmette. La specifica stessa mostra un flusso multisig 2 di 3 e un coinjoin manuale, e dice che il formato consente a chi firma offline, come i portafogli hardware, di farlo senza accesso diretto all’insieme delle monete non spese. La nostra guida su come funzionano le transazioni crypto spiega da zero input, output e commissioni.
Il punto è che una PSBT non dimostra gli importi che dichiara. I record degli input sono dati forniti da chi ha costruito il file. Chi firma con prudenza li confronta con le vere transazioni precedenti prima di fidarsi di qualsiasi cifra sulla commissione, e librerie come bitcoinjs-lib offrono un controllo sul tasso di commissione come ultima difesa. Questi due bug hanno ingannato proprio quel controllo, ed è per questo che gli avvisi mettono in guardia le app che si affidano a getFee() o alla verifica predefinita.
Chi è esposto ai bug sulle commissioni delle PSBT: la lettura di Coindaro
Né i manutentori né CryptoSlate hanno elencato app esposte. Secondo la lettura che Coindaro fa del testo degli avvisi, l’esposizione richiede tre condizioni insieme: un’app costruita su una versione colpita, una PSBT che arriva da qualcun altro (un cofirmatario, un server coordinatore, una dApp) e un’app che si fida della cifra sulla commissione della libreria prima di firmare e trasmettere. Il primo avviso dice effettivamente che lo sfruttamento richiede che l’app accetti i dati in conflitto e proceda senza verificare da sé le monete reali; il resto di questa sezione è una nostra interpretazione.
Un portafoglio che costruisce le proprie transazioni a partire da dati sulle monete recuperati da sé non è, a nostro avviso, il caso descritto dagli avvisi. Se non sai a quale tipo appartenga lo strumento che usi, la nostra pagina su wallet crypto e custodia descrive i tipi principali.
Non è il difetto di Electrum sul rialzo delle commissioni del 25 ottobre
La tempistica invita alla confusione. Tre giorni prima Coindaro aveva raccontato un altro difetto legato alle commissioni in Electrum, in cui un server malevolo nascondeva il pagamento in sospeso reale dell’utente e il successivo rialzo della commissione, fatto dall’utente stesso, firmava un furto. Quel bug è stato sfruttato e almeno un utente ha perso dei fondi. Vive in Electrum, un portafoglio scritto in Python corretto nella versione 4.8.3, e richiede un server malevolo.
I bug di bitcoinjs-lib stanno in una libreria JavaScript, non coinvolgono alcun server e non hanno vittime note. La commissione in eccesso andrebbe ai miner e non all’indirizzo di un aggressore. Ad accomunare le due storie è solo la parola commissione.
Sicurezza del wallet bitcoin: cosa devono fare ora sviluppatori e utenti
Per gli sviluppatori, gli avvisi sulle commissioni chiedono almeno la 7.0.4, la 6.1.9 o la 5.2.2. Passare direttamente alla 7.0.5, alla 6.1.10 o alla 5.2.3 recupera anche la correzione sulla proof of work. Conviene controllare anche il lockfile, perché la libreria arriva spesso tramite un altro pacchetto. Se non è possibile aggiornare, bisogna verificare da sé gli output referenziati e rifiutare ogni PSBT in cui i due record UTXO non coincidono. Disattivare i controlli sulle commissioni non è una soluzione, aggiungono i manutentori.
Gli utenti dei portafogli non possono correggere da soli una libreria. Possono però aggiornare le proprie app e, quando una PSBT arriva da qualcun altro, guardare quali monete vengono spese e quanto vale ciascuna, e non solo la riga della commissione, prima di approvare. Una commissione che sembra troppo bassa rispetto alla dimensione del pagamento merita un secondo sguardo. Il wallet con cui firmi è attento quanto i dati che controlla.
Nessuna autorità europea o italiana si è espressa sugli avvisi: non risultano comunicazioni di Consob, OAM o Banca d’Italia. Le società dell’UE che gestiscono wallet per i clienti sotto MiCA e si appoggiano a strumenti JavaScript sono nella stessa situazione di tutti gli altri: la soluzione è un aggiornamento.
Che cosa non si sa ancora sugli avvisi di bitcoinjs-lib
Nessuna app è stata indicata come colpita, né dai manutentori né da CryptoSlate. Non è stato descritto alcun sfruttamento in corso. I segnalatori sono noti solo per il nome utente su GitHub, e i due bug sulle commissioni non hanno per ora un numero CVE. Il prossimo elemento da seguire è se i progetti di wallet e multisig che dipendono da bitcoinjs-lib pubblicheranno proprie comunicazioni sulle versioni che hanno distribuito.