Bitcoin Core ujawnia groźny błąd bezpieczeństwa: możliwe zatrzymanie węzłów```

W jaki sposób błąd w Bitcoin Core mógłby spowodować zatrzymanie operacji wydobywczych?

Najpoważniejsza luka, oznaczona jako CVE-2025-62861, dotyczyła wersji Bitcoin Core od 28.0 do 28.2 oraz od 29.0 do 29.1. Uchybienie to, sklasyfikowane jako o wysokim stopniu zagrożenia, dotyczyło obsługi transakcji podczas reorganizacji łańcucha bloków, co potencjalnie mogło uniemożliwić węzłom wydobywczym tworzenie prawidłowych szablonów bloków.

W centrum problemu znajdowały się transakcje wersji 3, powszechnie nazywane transakcjami TRUC, które działają w ramach specjalnych ograniczeń mempoolu. Podczas reorganizacji łańcucha Bitcoin Core mógł nieprawidłowo usuwać transakcje, zachowując jednocześnie transakcje zależne, co powodowało niespójności w puli transakcji.

Dla górników konsekwencje były szczególnie kłopotliwe. Dotknięte wadą węzły mogły nie przejść walidacji szablonów bloków, co skutecznie uniemożliwiało im generowanie nowych zadań wydobywczych do momentu ponownego uruchomienia. Sprzęt wydobywczy mógł nadal haszować nieaktualne szablony, co potencjalnie prowadziło do utraty opłat transakcyjnych i obniżenia wydajności operacyjnej.

Badacz bezpieczeństwa Niklas Goegge zgłosił tę usterkę 26 września 2025 r. Następnie programista Greg Sanders wprowadził poprawkę, wdrożoną 2 października, która zapobiegała problematycznemu usuwaniu transakcji podczas reorganizacji.

Poprawka pojawiła się w oprogramowaniu Bitcoin Core w wersjach 30.0, 29.2 i 28.3 w październiku 2025 r. Niemniej jednak około 9% dostępnych węzłów nadal ogłaszało podatne na atak wersje w okresie zbliżonym do daty ujawnienia luki.

Jakie były pozostałe dwie luki w zabezpieczeniach Bitcoin Core?

Druga luka, oznaczona jako CVE-2025-62859, została sklasyfikowana jako średniej ważności i dotyczyła złośliwie skonstruowanych kompaktowych bloków. Atakujący mógł wykorzystać nieprawidłową obsługę zmodyfikowanych świadków transakcji do wielokrotnego opóźniania pobierania bloków. W określonych warunkach sieciowych, w tym w przypadku zainfekowanych połączeń peer-to-peer o dużej przepustowości, zakłócenia mogły trwać w nieskończoność.

Badacz Eugene Siegel zidentyfikował tę lukę w kwietniu 2025 r. Gregory Sanders opracował poprawkę, która została wprowadzona w wersjach Bitcoin Core 30.0 i 29.2.

Tymczasem luka CVE-2025-62860 ujawniła zupełnie inny problem związany z przychodzącymi połączeniami Tor oraz uprawnieniami zaufanych węzłów. Gdy operatorzy konfigurowali opcjonalne ustawienie -whitelist w Bitcoin Core tak, aby uwzględniało adres ich demona Tor, przychodzące połączenia mogły błędnie przejmować uprawnienia przeznaczone dla zaufanych węzłów.

Te wyjątki osłabiły niektóre zabezpieczenia przed atakami typu „odmowa usługi” oraz ochronę prywatności. Bitcoin Core wskazał, że potencjalnie dotyczyło to tysięcy dostępnych węzłów sieci głównej, chociaż standardowe konfiguracje pozostały bezpieczne.

Dlaczego Bitcoin Core czekał aż do listopada, aby ujawnić te luki?

Ogłoszenia z 10 listopada były zgodne z ustalonym harmonogramem ujawniania informacji przez Bitcoin Core. Programiści wstrzymali się z podaniem szczegółów technicznych do momentu, gdy ostatnia podatna na ataki główna linia wydawnicza, 29.x, osiągnęła status końca cyklu życia 27 października 2026 r. W przeciwieństwie do trzech ujawnionych 28 października luk w zabezpieczeniach, których wykrycie wspomogła sztuczna inteligencja, kwestie te podlegały konwencjonalnemu procesowi embarga.

Co ważne, żadna z nich nie umożliwiała kradzieży bitcoinów, nieautoryzowanego tworzenia monet ani załamania konsensusu, a także nie zgłoszono żadnych przypadków ich wykorzystania. Luka dotycząca kopania wymagała spełnienia określonych warunków reorganizacji, co oznacza, że jej konsekwencje ograniczały się do operatorów, których dotyczyła, a nie do samej sieci Bitcoin.

Dla górników bitcoinów i administratorów węzłów to rozróżnienie ma znaczenie. Konserwacja oprogramowania pozostaje niezbędna, nawet jeśli luki w zabezpieczeniach nie mogą narazić środków na niebezpieczeństwo. Ten incydent ilustruje, w jaki sposób pozornie niejasne błędy w obsłudze transakcji mogą powodować namacalne problemy operacyjne, nie zagrażając przy tym podstawowemu konsensusowi sieci.