Un miner putea împinge un fișier undo din Bitcoin Core peste 4 GiB, ceea ce dădea peste cap pozițiile pe 32 de biți și corupea datele, astfel că nodurile se opresc dacă urmează reorganizarea potrivită; pe Windows și pe sistemele de 32 de biți eșecul apare la 2 GiB, fără reorganizare. CVE-2026-117346 are severitate scăzută și ar cere cam o lună din toate blocurile rețelei. Versiunile 32.1, 31.2, 30.4 și 29.5 repară sistemele de 64 de biți; nodurile de 32 de biți și stocarea blocurilor pe FAT32 rămân afectate.
Monitorizarea excepțiilor de socket funcționează acum la fel în poll() și select() în Bitcoin Core 29.5 (#36665), iar peerii cu trimiterea în pauză au un timeout impus (#36667). Pozițiile din flatfile trec pe întregi de 64 de biți (#36669), nodurile presupun v2transport pentru adresele primite de la seeduri, iar un seed DNS dispare din listă.
Prefăcându-se că nu suportă pingurile BIP 31, un peer rău intenționat putea evita deconectarea de după 20 de minute și citea lent, umflând coada de trimitere a nodului cu până la 2 MB pe oră pentru fiecare peer de intrare și 5 MB pentru fiecare peer de ieșire. CVE-2026-117349, de severitate medie, e reparat prin #36667 în Bitcoin Core 32.1, 31.2, 30.4 și 29.5; nodurile -blocksonly erau mult mai puțin expuse.
Nodurile pe Windows, macOS și BSD puteau fi doborâte de un peer conectat care trimitea date urgente TCP: acestea treceau de citirile suspendate din backendul select() și ocupau memorie fără limită (CVE-2026-117350). Pe Linux, unde nodurile folosesc poll(), problema nu există. Bugul, de severitate medie, a ieșit la iveală la o scanare cu LLM din cadrul Project Loupe și e reparat în Bitcoin Core 32.1, 31.2, 30.4 și 29.5.
Bitcoin Core 30.4 nu mai tratează biții 5-28 din BIP 9 drept semnale de soft fork, conform BIP 323, așa că blocurile care îi setează nu mai declanșează avertismente despre activări necunoscute (#34779). La capitolul rețea apare un timeout impus peerilor cu trimiterea în pauză (#36667), iar pozițiile din flatfile trec pe întregi de 64 de biți (#36669).
Private broadcast primește o limită în Bitcoin Core 31.2: coada tranzacțiilor pe care rețeaua nu le-a trimis încă înapoi se oprește la 10.000 de poziții și, odată plină, refuză alte trimiteri, iar golirea ei rămâne pe seama apelantului, prin abortprivatebroadcast (#35406). Conform BIP 323, biții de versiune 5-28 nu mai contează ca semnale de soft fork.
Private broadcast din Bitcoin Core 32.1 nu mai riscă să expună adresa IP a expeditorului, scurgere posibilă atunci când o conexiune v2 eșuată se relua pe v1 direct, nu prin Tor. Valoarea implicită a -maxconnections urcă de la 125 la 200, iar retransmiterea tranzacțiilor către peeri are o limită de rată printr-un backlog global, nu per peer.
Citirile și scrierile intense pe disc din timpul funcționării normale aveau drept cauză un bug reparat în Bitcoin Core 29.4: baza de date chainstate își rescria mereu părți mari din ea însăși. Remedierea dezactivează seek compaction în LevelDB și compactează periodic chainstate-ul (#35465).
Rescrierile excesive pe disc ale chainstate-ului dispar în Bitcoin Core 30.3, care mai repară un crash al feebumper când comisionul combinat de bump nu e disponibil (#34870) și un bug din selecția de monede care calcula o sumă ca valoare booleană (#34888). În zona PSBT, cheile publice MuSig2 sunt acum validate la deserializarea pubnonce și a semnăturilor parțiale (#34219).
Bitcoin Core 31.1 închide o scurgere de adresă IP din -privatebroadcast: unele conexiuni plecau pe clearnet, nu prin rețeaua de confidențialitate activată. Actualizarea pune capăt și rescrierilor chainstate care provocau activitate excesivă pe disc și respinge o listă goală de chei publice la agregarea de chei MuSig2 (#35316).
Bitcoin Core
Buletin de securitateDezvoltare3 minute de lectură
Un handshake v2 eșuat poate expune adresa IP a expeditorului în Bitcoin Core 31.0: cu -privatebroadcast activ, reîncercarea pe v1 ocolește proxy-ul Tor și se conectează direct la peer. Declanșatorul probabil e un peer rău intenționat care închide handshake-ul dinadins. Până apare 31.1, utilizatorii pot dezactiva funcția, pot seta -v2transport=0 sau pot trimite traficul de ieșire IPv4/IPv6 prin Tor.
Bitcoin Core
Buletin de securitateDezvoltare2 minute de lectură
Versiunile Bitcoin Core ulterioare 0.14.0 și anterioare 29.0 puteau citi memorie eliberată la validarea unui bloc invalid special construit, ceea ce prăbușea nodul. CVE-2024-52911 are severitate ridicată, deși atacatorul trebuie să cheltuie proof-of-work valid la vârful lanțului, iar execuția de cod la distanță e considerată puțin probabilă. A raportat-o Cory Fields, iar remedierea vine cu 29.0.
Bitcoin Core 31.0 trece la cluster mempool: limitele pentru ascendenți și descendenți fac loc unor clustere de cel mult 64 de tranzacții și 101 kB, iar CPFP carveout dispare. -dbcache implicit urcă la 1024 MiB pe mașinile cu cel puțin 4096 MiB RAM, iar noua opțiune -privatebroadcast trimite tranzacțiile din sendrawtransaction doar prin Tor sau I2P.
Două eșecuri legate de portofelele fără nume primesc remedieri în Bitcoin Core 28.4: migrarea portofelelor legacy (#34156) și createfromdump, care la eșec ștergea directorul de portofele (#34215). Din chainparams mai dispare și un seed DNS (#33723).
Bitcoin Core 29.3 nu mai penalizează peerii care trimit tranzacții invalide conform consensului (#33050). Validarea câștigă un cache de sighash midstate pe fiecare intrare pentru scripturi legacy, P2SH și segwit v0 (#32473) și detectează witness stripping fără a relua verificările Script (#33105), iar addPackageTxs din miner scapă de o depășire de întreg fără semn (#33475).
Eșecul la migrarea portofelelor legacy fără nume dispare în Bitcoin Core 30.2 (#34156), iar createfromdump nu mai șterge directorul de portofele când eșuează pe unul dintre ele (#34215). Apăsarea Ctrl-C nu mai blochează programul în timpul apelurilor de așteptare IPC (#33511).
În condiții rare, o migrare wallet.dat eșuată în Bitcoin Core 30.0 sau 30.1 poate șterge toate fișierele din directorul de portofele, punând fondurile în pericol. Dezvoltatorii au retras aceste binare și le cer utilizatorilor să nu migreze prin GUI sau RPC până la 30.2. Bugul apare doar la un wallet.dat implicit, fără nume, care nu reușește să migreze sau să se încarce; ceilalți utilizatori nu sunt afectați.
Portofelele din Bitcoin Core 30.1 nu mai iau în calcul monedele TRUC neconfirmate care au ascendenți (#33528). În zona IPC, opțiunile nu mai cer argumentul -m (#33229), jurnalizarea mesajelor consumă mai puțin (#33517), iar apelurile waitNext aflate în curs pot fi anulate (#33676).
Bitcoin Core
Buletin de securitateDezvoltare2 minute de lectură
Tranzacții nestandard special construite puteau ține ocupat un nod Bitcoin Core câteva secunde fiecare, fără ca expeditorul să fie deconectat, iar un atacator putea astfel întârzia propagarea blocurilor. Antoine Poinsot a raportat CVE-2025-46598, de severitate scăzută, iar v30.0 o atenuează prin reducerea timpului de validare în cel mai rău caz.
Bitcoin Core
Buletin de securitateDezvoltare2 minute de lectură
Blocurile de peste 1 GB puteau depăși o verificare de dimensiune pe nodurile Bitcoin Core de 32 de biți și le prăbușeau la scrierea pe disc, însă doar sub formă de compact block și doar la o victimă cu -maxmempool peste 3 GB și 1 GB de tranzacții în mempool. Pieter Wuille a descoperit CVE-2025-46597, de severitate scăzută; plafonarea -maxmempool pe sistemele de 32 de biți a închis problema în 29.1 și 30.0.
