Una vulnerabilità scoperta di recente (CVE-2024-52911) permetteva a un blocco confezionato in un modo speciale — ma con Proof-of-Work valido — di far crashare i nodi Bitcoin Core. In casi estremi, poteva anche permettere l’esecuzione di codice remoto (RCE), anche se molto difficile.

In pratica: un attaccante con abbastanza potenza di calcolo poteva far “cadere” i nodi degli altri, interrompendo temporaneamente la verifica della blockchain. La correzione è arrivata con la versione 29.0 di Bitcoin Core.

Dettagli tecnici: come funzionava il bug

Il problema è un classico use-after-free nel validatore di script di Bitcoin Core, presente dalle versioni successive alla 0.14.0 fino alla 28.x (prima della 29.0).

Durante la validazione di un blocco, Bitcoin Core pre-calcola e cachea dati necessari per verificare gli input di ogni transazione (oggetti PrecomputedTransactionData). Questi dati vengono usati da thread in background tramite una struttura CScriptCheck.

Normalmente, un meccanismo RAII (CCheckQueueControl) gestisce la durata di vita di questi controlli. Tuttavia, a causa dell’ordine di distruzione degli oggetti locali in C++ (distruttori chiamati in ordine inverso rispetto alla costruzione), il vettore di PrecomputedTransactionData veniva distrutto prima del CCheckQueueControl in certi percorsi di errore.

Quando il blocco era valido, tutto andava bene perché Wait() veniva chiamato prima della distruzione. Ma con blocchi invalidi crafted appositamente, un thread di validazione in background poteva accedere a memoria già liberata (use-after-free). Questo causava crash o, potenzialmente, comportamenti imprevedibili sfruttabili per RCE.

L’attaccante doveva però minare un blocco con PoW sufficiente a raggiungere la tip della catena (o quasi), rendendo l’attacco costoso ma teoricamente possibile. Bitcoin Core ha classificato la vulnerabilità come High severity.

Timeline e fix

• Novembre 2024: Cory Fields scopre e riporta privatamente il bug con PoC.
• Dicembre 2024 / 2025: Fix covert inserito in una PR esistente (#31112) rimuovendo early returns problematici.
• Aprile 2025: Rilascio di Bitcoin Core 29.0 con la correzione.
• Aprile 2026: La versione 28.x raggiunge End-of-Life.
• 5 Maggio 2026: Divulgazione pubblica.

Commenti degli utenti su X (ex Twitter)

La divulgazione ha generato diverse reazioni nella community:

• Molti hanno criticato Bitcoin Core definendolo “dumpster fire” (incendio in una discarica) e invitato a passare a fork come Bitcoin Knots + BIP-110 per maggiore qualità e sicurezza. Alcuni suggeriscono soluzioni più estreme come DATUM + Ocean per mining indipendente.

• Luke Dashjr (sviluppatore Core) ha notato che il fix non è stato backportato nella 28.x nonostante non fosse ancora EOL.

• Proponenti di altre implementazioni (come eCash/XEC e Bitcoin ABC) hanno sottolineato che un fix simile era stato applicato 9 anni prima (2017) grazie a pratiche di defensive programming di deadalnix. Hanno usato l’occasione per parlare di maggiore robustezza delle loro codebase.

• Utenti più pragmatici hanno semplicemente confermato di essere già aggiornati alla v29 o v30 (“Good thing that I’m on v30”).

• Dibattiti accesi tra sostenitori di Knots e difensori di Core, con accuse reciproche di scarsa competenza tecnica.

Conclusioni

Questa vulnerabilità ricorda quanto sia critica la manutenzione del software che gestisce centinaia di miliardi di dollari. Anche se l’attacco richiedeva PoW significativo, dimostra che bug di memoria in C++ possono avere conseguenze reali sulla rete Bitcoin.

Raccomandazione: aggiorna subito il tuo nodo a Bitcoin Core 29.0 o superiore (o a un fork mantenuto come Knots). Come sempre in Bitcoin: don’t trust, verify. Verifica le firme delle release e monitora le advisory ufficiali.

La sicurezza di Bitcoin dipende dalla salute e dall’aggiornamento dei nodi pieni gestiti dalla community.