Bitcoin Core opublikował w listopadzie 2026 roku szczegóły trzech luk bezpieczeństwa, około rok po tym, jak poprawki zostały już wydane. Najpoważniejsza z nich, oceniona jako wysoka (High), mogła uniemożliwić węzłom wydobywczym tworzenie poprawnych szablonów bloków po reorganizacji łańcucha.

Bitcoin Core to referencyjna implementacja protokołu Bitcoin. Węzły w sieci opierają się na tym oprogramowaniu open source przy walidacji i przekazywaniu transakcji oraz bloków, a górnicy i pule wydobywcze używają go do tworzenia szablonów bloków z niepotwierdzonych transakcji w mempoolu, czyli obszarze przechowywania oczekujących transakcji.

Zgodnie z polityką projektu luki są ujawniane dopiero po pewnym opóźnieniu: najpierw poprawka trafia do wydania, a opis techniczny pojawia się dopiero wtedy, gdy dotknięte wersje staną się przestarzałe. Poprawki tych luk trafiły do wersji 30.0, 29.2 i 28.3, wszystkich wydanych w październiku 2025 roku. Komunikaty noszą identyfikatory CVE-2025-62861, CVE-2025-62859 i CVE-2025-62860 — standardowe identyfikatory, pod którymi katalogowane są publicznie ujawnione luki w oprogramowaniu. CVE-2025-62861 ma ocenę High; pozostałe dwie są ocenione jako Medium. W związku z tym projekt opublikował komunikaty zaledwie 14 dni po zakończeniu wsparcia dla serii 29.x, ostatniej podatnej linii wydań. Pełne treści są dostępne w oficjalnym ujawnieniu oraz w indeksie komunikatów bezpieczeństwa projektu.

Jak reorganizacja mogła zablokować węzły wydobywcze

Luka o wysokiej wadze, CVE-2025-62861, dotyczy wersji od 28.0 do 28.2 oraz od 29.0 do 29.1. Zgłosił ją Niklas Goegge we wrześniu 2025 roku. Defekt wywodzi się z TRUC — skrótu od Topologically Restricted Until Confirmation — znanych również jako transakcje v3. Ta polityka mempoola nakłada ścisłe ograniczenia na to, jak niepotwierdzone transakcje mogą od siebie zależeć, a jej głównym celem jest pomoc protokołom warstwy drugiej, takim jak Lightning Network, w podnoszeniu opłat po fakcie. Wersja 28.0 dodała kolejną regułę zwaną sibling eviction: nowa transakcja może próbować dodać drugie dziecko do transakcji nadrzędnej TRUC, a jeśli zapłaci wystarczającą opłatę, zastępuje istniejące dziecko.

Błąd ujawnił się podczas reorganizacji, w skrócie "reorg" — zdarzenia, w którym sieć zastępuje najnowściej dodane bloki innym łańcuchem. Bitcoin Core najpierw zwraca transakcje z odłączonych bloków do mempoola z flagą bypass_limits=true. Gałąź sibling eviction jednak nie respektowała tej flagi i i tak się wykonywała. W rezultacie reguła usuwała transakcję, podczas gdy jej potomki pozostawały w mempoolu, przez co mempool zawierał transakcje wydające nieistniejące już wyjścia. Za każdym razem, gdy węzeł próbował wtedy zbudować nowe szablony bloków, weryfikacja poprawności kończyła się niepowodzeniem.

Dotknięci górnicy mogli ponownie tworzyć poprawne szablony dopiero po restarcie węzła, ponieważ restart przeładowuje mempool w spójnym stanie. Mimo to komunikat dotyczący CVE-2025-62861 nie wymienia żadnego obejścia poza aktualizacją. Greg Sanders dostarczył poprawkę w PR #33504, który projekt scalił z główną gałęzią w październiku 2025 roku i przeniesił (backport) do linii 28.x, 29.x i 30.x. Luka dotyczyła wyłącznie tworzenia szablonów: ponieważ TRUC to reguła mempoola, a nie reguła konsensusu, błąd nie naruszał konsensusu. Reguły mempoola, takie jak TRUC, to lokalne polityki stosowane przez każdy węzeł do własnych oczekujących transakcji, w przeciwieństwie do reguł konsensusu, które każdy węzeł wymusza na współdzielonym łańcuchu.

Dwie luki o średniej wadze dotyczą przekazywania bloków i peerów Tor

CVE-2025-62859 dotyczy wersji starszych niż 29.2 i starszych niż 30.0. Eugene Siegel zgłosił tę lukę już w kwietniu 2025 roku. Znajduje się w obsłudze compact block, czyli skróconego formatu, którego węzły używają do przekazywania sobie nowych bloków. Dotknięte wersje czyściły stan pobierania takiego bloku przed sprawdzeniem witness malleation, czyli po fakcie dokonanej modyfikacji danych witness. Jeśli to sprawdzenie nie powiodło się, węzeł ponownie żądał danych od tego samego peera za pomocą GETDATA, z limitem czasu 10 minut — w przybliżeniu odpowiadającym średniemu odstępowi między blokami Bitcoina. Złośliwy peer, który pierwszy ogłosił compact block, mógł więc opóźnić przetwarzanie bloku u ofiary nawet o 10 minut. Co więcej, atakujący mógł powtarzać atak bez ograniczeń w trybie -blocksonly lub gdy kontrolował wszystkich trzech peerów o wysokim pasmie — małą grupę peerów, od których węzeł oczekuje priorytetowych ogłoszeń bloków. PR #32646, scalony w czerwcu 2025 roku, naprawił ten błąd.

Druga luka o średniej wadze, CVE-2025-62860, dotyczy wersji starszych niż 28.3, 29.2 i 30.0. Martin Zumsande i Antoine Poinsot zgłosili ją we wrześniu 2025 roku, dwa tygodnie przed zgłoszeniem przez Goegge'a luki o wysokiej wadze. W Bitcoin Core przychodzące połączenia Tor pojawiają się pod adresem IP demona Tor, czyli lokalnej usługi przekazującej ruch z sieci anonimowej. Jeśli ten adres mieścił się w zakresie IP dozwolonym przez -whitelist, wszyscy przychodzący peerzy Tor otrzymywali uprawnienia whitelist. Te uprawnienia znoszą limity DoS i zabezpieczenia przed wyciekami prywatności.

Według komunikatu "tysiące" osiągalnych węzłów mainnet nadało te uprawnienia wszystkim przychodzącym połączeniom Tor. Często opcję tę ustawiali dostawcy, którzy dostarczają Bitcoin Core w pakiecie z demonem Tor. W przeciwieństwie do tego luka nigdy nie dotknęła węzłów bez tej opcjonalnej, niedomyślnej konfiguracji. Od PR #33395 Bitcoin Core nie uwzględnia już przychodzących peerów Tor przy nadawaniu uprawnień whitelist.

Projekt ocenia obie luki jako Medium. Opóźnienie w przetwarzaniu bloków było tymczasowe, a atakujący mogli je powtarzać dowolnie tylko w konkretnych konfiguracjach, natomiast luka Tor wymagała konfiguracji odbiegającej od domyślnej.

Dlaczego między poprawką a ujawnieniem minął rok

Bitcoin Core celowo rozdziela poprawkę od ujawnienia. Poprawka trafia najpierw do zwykłego wydania, a projekt nie opisuje wtedy luki; szczegóły następują później, gdy dotknięte wersje staną się starsze lub osiągną koniec wsparcia. To daje operatorom czas na aktualizację.

W przypadku trzech aktualnych komunikatów zgłoszenia napływały od kwietnia do września 2025 roku, a poprawki trafiały do kodu od czerwca do października 2025 roku. Bitcoin Core 30.0, 29.2 i 28.3 zostały następnie wydane z poprawkami w październiku 2025 roku. O terminie ujawnienia zdecydował koniec wsparcia: wsparcie dla serii 29.x, ostatniej podatnej linii wersji, zakończyło się 27 października 2026 roku, a komunikaty opublikowano 10 listopada 2026 roku — 14 dni później.

Indeks komunikatów projektu stosuje cztery poziomy wagi: Critical, High, Medium i Low. Wszystkie trzy komunikaty mieszczą się na środkowych poziomach. Wyróżnia się okres dla CVE-2025-62859: Siegel zgłosił lukę w kwietniu 2025 roku, projekt scalił poprawkę w czerwcu 2025 roku, a szczegóły stały się publiczne dopiero nieco ponad 18 miesięcy po zgłoszeniu.

Co te luki oznaczają dla górników i operatorów węzłów

Luka o wysokiej wadze dotknęła głównie górników i puli wydobywcze. Błąd uruchamiały tylko węzły, które przeszły przez reorg, a następnie musiały tworzyć szablony bloków. W przeciwieństwie do tego dwie luki o średniej wadze dotknęły również zwykłych węzłów, choć każda z nich wymagała konkretnej sytuacji sieciowej lub konfiguracji.

Wersje 30.0 i 29.2 naprawiają wszystkie trzy błędy, a 28.3 naprawia dwa z nich. Od końca października 2026 roku jednak wsparcie otrzymują tylko wersje od 30.x wzwyż. Każdy, kto korzysta z wersji 29.x lub starszej, używa więc nieobsługiwanego oprogramowania, nawet z backportami.

Komunikaty pozostawiają kilka pytań otwartych. Na przykład nie jest jasne, czy atakujący może celowo stworzyć topologię reorg uruchamiającą lukę o wysokiej wadze. Komunikaty nie mówią też, czy któraś z trzech luk została kiedykolwiek wykorzystana, a dokładna liczba węzłów dotkniętych luką Tor nie jest znana. Z dokumentacji wynika jednak, że projekt naprawił i wydał wszystkie trzy poprawki nieco ponad rok przed ujawnieniem.