Luka w BTCPay wykorzystywana: sama aktualizacja nie wystarczy

BTCPay Server, samodzielnie hostowane oprogramowanie płatnicze, dzięki któremu sklepy internetowe mogą przyjmować bitcoina, ostrzegł 7 sierpnia 2026 roku przed luką, która w tym momencie była już aktywnie wykorzystywana. Wersja 2.4.2, wydana 8 sierpnia, zamyka tę lukę. Kto korzysta ze starszej wersji, ryzykuje utratę środków.

Błąd tkwił w warstwie uwierzytelniania Greenfield API. Kod sprawdzał, czy zarejestrowano klucz bezpieczeństwa FIDO2, zamiast tego, czy weryfikacja dwuetapowa jest w ogóle włączona. Użytkownicy zwykłej aplikacji uwierzytelniającej najczęściej nie mają klucza FIDO2, więc w ich przypadku API pomijało drugi etap w całości. Wystarczały adres e-mail i hasło.

Co już się wydarzyło

Node Lightning należący do samej BTCPay Foundation został opróżniony, zanim ostrzeżenie trafiło do opinii publicznej. Tak samo skończył node Citadel21, prowadzony przez Hodlonauta. Co najmniej jeden inny operator zgłosił to samo. Łącznej kwoty nie ujawniono.

Lukę znalazł Craig Raw, twórca Sparrow Wallet, po tym jak jego własny node został przejęty. Przebieg ataku odtworzył na podstawie logów serwera.

Aktualizacja to pierwszy krok, nie ostatni

To właśnie ten etap najczęściej się sypie, a waży tu więcej niż sama aktualizacja. Dane logowania do twojego node’a Lightning, czyli macaroons, leżą na dysku w postaci plików. Napastnik, który wszedł przed łatką, mógł je skopiować. Potem działają dalej, bo aktualizacja nic w tym nie zmienia.

Zgodnie z zaleceniami projektu po aktualizacji trzeba też wymienić dane dostępowe do Lightning: usuń macaroons.db oraz wszystkie pliki macaroon i uruchom node ponownie. Przenieś ponadto saldo swojego hot wallet on-chain na nowy wallet, a w integracjach przejdź na klucze API o ograniczonym zakresie zamiast pełnego dostępu. Łatka domyślnie wyłącza odtąd Basic Authentication, pięć minut po założeniu konta. Poza samym BTCPay dostępna jest odpowiadająca jej aktualizacja NBXplorer w wersji 2.6.10.

Co to mówi o testach automatycznych

W tej historii jest niewygodny szczegół. Audyt Bitcoin Red Team, zakończony 5 sierpnia, przeszedł w 27,5 godziny przez 390 projektów open source i przyniósł 4962 ustalenia, w tym 85 krytycznych. Tej luki wśród nich nie było.

To nie czyni audytu bezwartościowym, ale koryguje wrażenie, jakie taka liczba potrafi wywołać. Automatyczne wyszukiwanie znajduje wzorce, które zna. Błąd logiczny polegający na sprawdzaniu niewłaściwego warunku, w którym kod robi dokładnie to, co w nim napisano, tyle że napisano w nim coś niewłaściwego, z łatwością mu umyka. Lukę ostatecznie znalazł ktoś, kto po kradzieży przekopał własne logi.

Co z tego wynika dla ciebie

Jeśli sam prowadzisz instancję BTCPay, kolejność jest taka: najpierw aktualizacja do 2.4.2 przez Admin Dashboard, Server, Maintenance, Update, a potem sprawdzenie w stopce, czy faktycznie widnieje tam 2.4.2. Jeśli nie możesz zaktualizować od razu, wyłącz instancję do czasu, aż będzie to możliwe.

Następnie wymień macaroons i przenieś środki z hot wallet. Jeśli pominiesz ten krok, wymienisz zamek, ale stary klucz zostawisz poprzedniemu lokatorowi.

Jeśli nie używasz BTCPay, ale prowadzisz sklep internetowy przyjmujący bitcoina, zapytaj swojego dostawcę płatności, jaka wersja u niego działa. I szersza lekcja, która obowiązuje nawet wtedy, gdy z Lightning nie masz nic wspólnego: po włamaniu zmiana hasła rzadko wystarcza. Tokeny sesji, klucze API i powiązane urządzenia działają do chwili, w której sam je unieważnisz.

Źródła: BTCPay Server (ostrzeżenie z 7 sierpnia 2026 roku), Craig Raw (Sparrow Wallet), TechTimes (8 sierpnia 2026 roku), Crypto Briefing. Ostatnio sprawdzono: 9 sierpnia 2026 roku.