Майнер міг роздути undo-файл Bitcoin Core понад 4 ГіБ: 32-бітні позиції переповнювалися, дані псувалися, і за відповідної реорганізації вузол вимикався. На Windows і 32-бітних системах збій настає вже на 2 ГіБ, причому реорганізація не потрібна. CVE-2026-117346 має низький рівень серйозності, а на атаку пішов би приблизно місяць усіх блоків мережі. Версії 32.1, 31.2, 30.4 і 29.5 лікують 64-бітні системи; 32-бітні вузли та сховища блоків на FAT32 лишаються під загрозою.
Моніторинг винятків сокетів у Bitcoin Core 29.5 тепер однаковий для poll() і select() (#36665), а для пірів, надсилання яким призупинено, запроваджено обов’язковий тайм-аут (#36667). Позиції у flatfile перейшли на 64-бітні цілі числа (#36669), вузли вважають, що адреси із сидів підтримують v2transport, а один DNS-сид вилучено.
Удаючи, що не підтримує пінги BIP 31, зловмисний пір міг уникнути 20-хвилинного відключення й читати дані повільно. Черга надсилання вузла при цьому розпухала до 2 МБ на годину для кожного вхідного піра і до 5 МБ для кожного вихідного. CVE-2026-117349 середньої серйозності закриває #36667 у Bitcoin Core 32.1, 31.2, 30.4 і 29.5; вузли з -blocksonly були значно менш вразливі.
Підключений пір міг покласти вузол на Windows, macOS чи BSD, надсилаючи термінові дані TCP: вони обминали призупинене читання в бекенді select() і без обмежень накопичувалися в пам’яті (CVE-2026-117350). Linux-вузли працюють через poll(), тож їх це не стосується. Помилку середньої серйозності, яку виявило LLM-сканування в межах Project Loupe, виправлено в Bitcoin Core 32.1, 31.2, 30.4 і 29.5.
Bitcoin Core 30.4 більше не вважає біти 5–28 із BIP 9 сигналами софтфорків, як того вимагає BIP 323, тож блоки з цими бітами перестали викликати попередження про невідоме розгортання (#34779). Серед мережевих змін — обов’язковий тайм-аут для пірів, надсилання яким призупинено (#36667), а позиції у flatfile тепер зберігаються в 64-бітних цілих числах (#36669).
Приватне поширення в Bitcoin Core 31.2 отримало стелю: черга транзакцій, які ще не повернулися з мережі, обмежена 10 000 записів. Заповнена черга відхиляє нові подання, а розчищати її доведеться самостійно через abortprivatebroadcast (#35406). Біти версії 5–28 згідно з BIP 323 більше не вважаються сигналами софтфорків.
Приватне поширення в Bitcoin Core 32.1 більше не ризикує розкрити IP-адресу відправника: витік міг статися, коли невдале v2-з’єднання повторювалося через v1 напряму, а не через Tor. Типове значення -maxconnections зросло зі 125 до 200, а вихідну ретрансляцію транзакцій тепер обмежує спільна черга, а не ліміт на кожного піра.
Інтенсивне читання й запис на диск під час звичайної роботи пояснюються багом, який виправляє Bitcoin Core 29.4: база chainstate постійно переписувала великі частини самої себе. Тепер seek compaction у LevelDB вимкнено, а chainstate ущільнюється регулярно (#35465).
Постійне навантаження на диск через chainstate зникає в Bitcoin Core 30.3. Також полагоджено збій feebumper, коли сукупна комісія за підвищення недоступна (#34870), і помилку вибору монет, що обчислювала суму як булеве значення (#34888). У PSBT публічні ключі MuSig2 тепер перевіряються під час десеріалізації pubnonce і часткових підписів (#34219).
Bitcoin Core 31.1 закриває витік IP-адреси в -privatebroadcast: частина з’єднань ішла через clearnet замість увімкненої мережі приватності. Оновлення також припиняє переписування chainstate, через яке диск працював надмірно, і відхиляє порожній список публічних ключів під час агрегації ключів MuSig2 (#35316).
Невдале v2-рукостискання здатне видати IP-адресу відправника в Bitcoin Core 31.0: із параметром -privatebroadcast повторна спроба через v1 оминає проксі Tor і йде напряму до піра. Найімовірніший тригер — зловмисний пір, що навмисно закриває рукостискання. Поки не вийшов 31.1, можна вимкнути функцію, задати -v2transport=0 або спрямувати вихідний IPv4/IPv6 через Tor.
Випуски Bitcoin Core після 0.14.0 і до 29.0 могли під час перевірки спеціально створеного недійсного блока прочитати вже звільнену пам’ять, і вузол падав. CVE-2024-52911 має високий рівень серйозності, хоча нападникові доводиться витрачати справжній proof-of-work на вершині ланцюга, а віддалене виконання коду вважається малоймовірним. Повідомив про помилку Cory Fields; виправлення містить 29.0.
Cluster mempool приходить на зміну старій архітектурі в Bitcoin Core 31.0: замість лімітів на предків і нащадків тепер діють кластери до 64 транзакцій і 101 кБ, а CPFP carveout скасовано. Типове значення -dbcache зросло до 1024 МіБ на машинах щонайменше із 4096 МіБ оперативної пам’яті, а новий параметр -privatebroadcast надсилає транзакції із sendrawtransaction лише через Tor або I2P.
Два збої з безіменними гаманцями виправлено в Bitcoin Core 28.4: під час міграції застарілого гаманця (#34156) та в createfromdump, який у разі невдачі видаляв каталог гаманців (#34215). Із chainparams також прибрано один DNS-сид (#33723).
Bitcoin Core 29.3 перестає карати пірів за транзакції, недійсні за консенсусом (#33050). Перевірка отримала кеш midstate для sighash на кожен вхід у скриптах legacy, P2SH і segwit v0 (#32473) та виявляє зрізання witness без повторного запуску Script-перевірок (#33105), а з addPackageTxs у майнера зникло переповнення беззнакового цілого (#33475).
Збою міграції безіменних застарілих гаманців у Bitcoin Core 30.2 більше немає (#34156), а createfromdump не видаляє каталог гаманців, коли не може обробити такий гаманець (#34215). Натискання Ctrl-C тепер не зависає під час викликів очікування IPC (#33511).
За рідкісних умов невдала міграція wallet.dat у Bitcoin Core 30.0 чи 30.1 може стерти всі файли в каталозі гаманців і поставити кошти під загрозу. Розробники відкликали ці бінарні файли й просять не запускати міграцію через GUI чи RPC до виходу 30.2. Помилка виникає лише з типовим безіменним wallet.dat, який не вдається перенести чи завантажити; решти користувачів вона не стосується.
Гаманці в Bitcoin Core 30.1 більше не розглядають непідтверджені монети TRUC, що мають предків (#33528). З боку IPC параметри перестали вимагати аргумент -m (#33229), логування повідомлень дає менше накладних витрат (#33517), а виклики waitNext, що вже виконуються, можна скасувати (#33676).
Спеціально зібрані нестандартні транзакції могли завантажувати вузол Bitcoin Core на кілька секунд кожна, і відправника при цьому не відключали, тож нападник мав спосіб затримувати поширення блоків. CVE-2025-46598 низького рівня виявив Antoine Poinsot, а у v30.0 проблему пом’якшили, скоротивши час перевірки в найгіршому випадку.
Блоки понад 1 ГБ могли переповнити перевірку розміру на 32-бітних вузлах Bitcoin Core й обвалити їх під час запису на диск, але лише у вигляді compact block і лише якщо жертва працює з -maxmempool понад 3 ГБ, маючи в мемпулі 1 ГБ транзакцій. Вразливість низького рівня CVE-2025-46597 знайшов Pieter Wuille; у 29.1 і 30.0 її закрило обмеження -maxmempool на 32-бітних системах.
