Bitcoin Core виявив критичну вразливість: можливий збій майнінгових вузлів

Як помилка в Bitcoin Core могла зупинити майнінг?

Найбільш серйозна вразливість, позначена як CVE-2025-62861, стосувалася версій Bitcoin Core від 28.0 до 28.2 та від 29.0 до 29.1. Ця вразливість, класифікована як високого рівня серйозності, стосувалася обробки транзакцій під час реорганізації блокчейну, що потенційно могло призвести до того, що майнінгові вузли не зможуть створювати валідні шаблони блоків.

В основі проблеми лежали транзакції версії 3, які зазвичай називають транзакціями TRUC і які працюють під спеціальними обмеженнями мемпулу. Під час реорганізації ланцюга Bitcoin Core міг помилково видаляти транзакції, зберігаючи при цьому залежні транзакції, що створювало невідповідності в його пулі транзакцій.

Для майнерів наслідки були особливо неприємними. Уражені вузли могли не пройти перевірку шаблонів блоків, що фактично унеможливлювало генерацію нових завдань для майнінгу до моменту перезапуску. Майнінг-обладнання могло продовжувати хешувати застарілі шаблони, що потенційно призводило до втрати комісій за транзакції та зниження операційної ефективності.

Дослідник у галузі безпеки Ніклас Гегге повідомив про цей дефект 26 вересня 2025 року. Згодом розробник Грег Сандерс запровадив виправлення, яке було інтегровано 2 жовтня, що запобігло проблемній поведінці видалення транзакцій під час реорганізацій.

Виправлення з’явилося в програмному забезпеченні Bitcoin Core 30.0, 29.2 та 28.3 протягом жовтня 2025 року. Проте приблизно 9 % доступних вузлів продовжували рекламувати вразливі версії на момент оприлюднення інформації.

Якими були дві інші уразливості безпеки Bitcoin Core?

Друга вразливість, CVE-2025-62859, мала класифікацію середнього рівня серйозності та пов’язана зі зловмисно сконструйованими компактними блоками. Зловмисник міг скористатися неналежним обробленням змінених свідчень транзакцій, щоб неодноразово затримувати завантаження блоків. За певних умов мережі, зокрема у разі скомпрометованих з’єднань з одноранговими вузлами з високою пропускною здатністю, таке втручання могло тривати нескінченно.

Дослідник Юджин Сігель виявив цю вразливість у квітні 2025 року. Грегорі Сандерс розробив виправлення, яке було впроваджено у версіях Bitcoin Core 30.0 та 29.2.

Тим часом уразливість CVE-2025-62860 виявила зовсім іншу проблему, пов’язану з вхідними з’єднаннями через Tor та правами доступу для довірених однорангових вузлів. Коли оператори налаштовували опціональний параметр -whitelist у Bitcoin Core, додаючи до нього адресу свого Tor-демона, вхідні з’єднання могли помилково успадковувати привілеї, призначені для довірених однорангових вузлів.

Ці винятки послаблювали певні заходи захисту від атак типу «відмова в обслуговуванні» та захисту конфіденційності. Розробники Bitcoin Core зазначили, що потенційно постраждали тисячі доступних вузлів основної мережі, хоча стандартні конфігурації залишалися безпечними.

Чому Bitcoin Core чекав до листопада, щоб оприлюднити ці вразливості?

Оголошення від 10 листопада відповідали встановленому графіку розкриття інформації Bitcoin Core. Розробники приховували технічні деталі доти, доки остання вразлива версія основної лінійки, 29.x, не досягне статусу «кінець терміну підтримки» 27 жовтня 2026 року. На відміну від трьох повідомлень про вразливості, опублікованих 28 жовтня за допомогою штучного інтелекту, ці проблеми були оприлюднені за традиційною процедурою ембарго.

Важливо зазначити, що жодна з них не давала можливості викрасти біткойни, створити монети без дозволу або порушити консенсус, і про випадки зловживання не повідомлялося. Вразливість у майнінгу вимагала конкретних умов реорганізації, а це означає, що її наслідки обмежувалися лише операторами, яких вона торкнулася, а не самою мережею Bitcoin.

Для майнерів біткойнів та адміністраторів вузлів це розрізнення має значення. Технічне обслуговування програмного забезпечення залишається необхідним навіть тоді, коли вразливості не можуть поставити під загрозу кошти. Цей випадок ілюструє, як, здавалося б, малопомітні дефекти в обробці транзакцій можуть створювати реальні операційні проблеми, не загрожуючи при цьому основному консенсусу мережі.