AI znalazła tysiące możliwych luk w projektach Bitcoina. Potwierdzenie ich wymaga czasu

Bitcoinowy ekosystem open source wszedł w nową fazę audytów bezpieczeństwa wspieranych przez AI. W sierpniowym sprincie 2026 r. wolontariacki Bitcoin Red Team podał, że w ciągu około 27,5 godziny przeanalizował mniej więcej 390 repozytoriów powiązanych z Bitcoinem. Zespół zgłosił 4962 potencjalne problemy bezpieczeństwa, z czego 85 sklasyfikował jako krytyczne, a 635 jako wysokiego ryzyka. To jednak tropy do sprawdzenia, a nie 4962 potwierdzone podatności możliwe do wykorzystania. I właśnie ta różnica jest najważniejsza. 1124

Co zrobił Bitcoin Red Team

16-osobową grupą kierowali deweloper Calle i Rob Hamilton, prezes AnchorWatch. Według relacji wykorzystano finansowane przez OpenSats zasoby obliczeniowe AI o wartości ponad 40 tys. dolarów. Ludzie wyznaczali kierunek pracy, a wiele modeli analizowało kod pod kątem podejrzanych ścieżek i możliwych słabości; następnie przygotowywano zgłoszenia dla opiekunów projektów. W doniesieniach wymieniano m.in. modele Kimi K3, GPT Sol, Fable, Opus i GLM 5.2. 2512

Skala krótkiej akcji była nietypowa: około 390 repozytoriów oraz środowisko audytowe, które według informacji obejmowało 171 599 linii kodu. Łącznie 720 zgłoszeń otrzymało oznaczenie „wysokie” lub „krytyczne”. 2327

To pokazuje, jak zmienia się ekonomika przeglądu kodu. Model może szybko przeszukiwać duży zbiór projektów, śledzić przepływy danych, wskazywać ryzykowne wzorce oraz proponować testy i hipotezy dotyczące exploitów. Samo wykrycie czegoś podejrzanego nie czyni jednak zgłoszenia gotowym do wdrożenia poprawki.

Dlaczego 4962 zgłoszenia nie oznaczają 4962 luk

Liczbę 4962 należy traktować jako kolejkę kandydatów wymagających weryfikacji. We wczesnych relacjach podano, że niezależnie odtworzono jedynie 21,4% wyników. W praktyce większość raportów wciąż wymaga ustalenia przez człowieka, czy dane zachowanie występuje w konkretnym wydaniu i konfiguracji, czy jest wykorzystywalne, czy nie dubluje innego zgłoszenia oraz jaka jest jego faktyczna waga. 1115

Pełna reakcja bezpieczeństwa zwykle obejmuje:

• odtworzenie problemu w rzeczywistym środowisku oprogramowania;
• oddzielenie prawdziwych luk od fałszywych alarmów i duplikatów;
• ocenę możliwości wykorzystania i skutków dla użytkowników;
• prywatne, skoordynowane ujawnienie problemu opiekunom projektu;
• przygotowanie precyzyjnej poprawki i testów;
• przegląd zmiany pod kątem regresji;
• wdrożenie aktualizacji przez operatorów i użytkowników.

AI znacząco obniżyła koszt pierwszego etapu, czyli generowania hipotez. Nie zniosła natomiast potrzeby eksperckiej odpowiedzialności na wszystkich kolejnych etapach. Z doniesień wynika też, że tylko część wyników dotarła już do opiekunów projektów, co pokazuje, że przepustowość procesu ujawniania problemów jest osobnym ograniczeniem. 14

Coldcard: stawka okazała się bardzo realna

Audyt nastąpił po incydencie z portfelami sprzętowymi Coldcard. Według relacji błąd w firmware z marca 2021 r. skierował generowanie seeda do przewidywalnego programowego generatora losowości zamiast do sprzętowego generatora liczb losowych. W konsekwencji klucze w dotkniętych urządzeniach mogły być odtwarzalne dla atakującego, który potrafił odpowiednio ograniczyć niezbędne dane wejściowe. 4245

Szacunki strat zmieniały się wraz z identyfikowaniem kolejnych działań. CoinDesk informował o możliwej łącznej kwocie bliskiej 114 mln dolarów w czterech falach, a inne relacje mówiły o około 1816 BTC skradzionych między 30 lipca a 3 sierpnia. 4142

Nie był to błąd kryptografii Bitcoina. Była to wada oprogramowania otaczającego mechanizm samodzielnego przechowywania środków. Przypadek pokazuje, że pojedyncza usterka może mieć skutki w skali całego ekosystemu — a znalezienie jej przed atakiem jest równie ważne jak analiza po fakcie.

Jest pierwsza poprawka, ale surowy wynik nie mówi o liczbie napraw

Wymiernym rezultatem był wkład Hamiltona do Bitcoin Core wsparty przez AI: 20 sierpnia, według doniesień, scalono poprawkę błędu powodującego awarię związaną z portfelem. To ważny przykład przejścia od wskazówki wygenerowanej lub wspartej przez AI do standardowego procesu przeglądu i akceptacji zmiany. 13

Zarazem dobrze pokazuje on ograniczenia wielkiej liczby z nagłówka. Scalona poprawka przeszła znacznie wyższy próg niż automatycznie wygenerowany raport: opisuje konkretny błąd, ma sprawdzoną łatę i została zaakceptowana w aktywnie utrzymywanym projekcie.

Ograniczenie dostępu do narzędzi OpenAI i dylemat obrońców

Hamilton przekazał, że program Trust Cyber firmy OpenAI ograniczył jego dostęp po rozpoczęciu integracji jej możliwości cyberbezpieczeństwa z audytem. Grupa miała następnie kontynuować pracę z alternatywnymi modelami, w tym modelami o otwartych wagach. 182132

To trudne pytanie o politykę dostępu. Zaawansowane modele cyberbezpieczeństwa mogą pomagać legalnym obrońcom wykrywać błędy, ale podobne możliwości można też nadużywać. Krytyka Hamiltona sprowadzała się do tego, że utrudnienia dla rozpoznanych badaczy mogą tworzyć praktyczną nierównowagę, jeśli atakujący nadal mają dostęp do innych modeli, w tym uruchamianych lokalnie. To argument o dostępie i tempie działania, a nie dowód, że ograniczenie narzędzi jednego dostawcy zatrzymuje badania bezpieczeństwa lub złośliwe użycie AI jako takie. 21

Boltz pokazuje presję na małe zespoły

Niezależnie od audytu usługa wymian bitcoinowych Boltz zawiesiła w sierpniu swapy na czas nieokreślony. Firma oświadczyła, że wzrost automatycznego, wspieranego przez AI sondowania jej infrastruktury przekroczył możliwości małego zespołu w zakresie zabezpieczania systemu i wdrażania poprawek. Funkcja zwrotów miała pozostać dostępna, mimo wyłączenia swapów. 282930

Boltz nie dowodzi, że każdy atak wygenerowany przez AI jest wyrafinowany lub skuteczny. Jest jednak praktycznym przykładem dysproporcji ujawnionej przez audyt Red Teamu: automatyczne wykrywanie i sondowanie może działać bez przerwy, podczas gdy opiekunowie projektów muszą pojedynczo zbadać każde ostrzeżenie i bezpiecznie dostarczyć każdą poprawkę.

Dlaczego lepsze modele zmieniają kalkulację ryzyka

Bitcoin oraz wiele usług wokół niego jest rozwijanych jako open source. Publiczny kod umożliwia niezależny przegląd i przejrzystość, ale jednocześnie udostępnia ten sam materiał zarówno obrońcom, jak i atakującym. Obawy Hamiltona i komentatora Bitcoina CobraBitcoin nie dotyczą tego, że otwarty kod jest z definicji niebezpieczny. Chodzi o to, że coraz sprawniejsze modele mogą skrócić czas i zmniejszyć próg wiedzy potrzebny do znalezienia nietypowej wady w setkach repozytoriów. 1721

OpenAI podaje, że GPT-6 Astra osiąga poziom Critical w jej Preparedness Framework dla zdolności cyberbezpieczeństwa. Firma twierdzi, że przy odpowiednich narzędziach i dostępie Astra potrafi znajdować nieznane wcześniej błędy oraz opracowywać sposoby ich wykorzystania w wielu dobrze zabezpieczonych systemach bez prowadzenia modelu przez człowieka krok po kroku. 1922

Nie oznacza to, że Astra była używana w audycie Bitcoin Red Team ani że za kompromitacją systemu Bitcoina stał model z czołówki. Wyjaśnia jednak, dlaczego opiekunowie projektów skupiają się na tempie reakcji. Jeśli modele będą coraz lepiej analizować całe repozytoria i rozwijać hipotezy o podatnościach, wąskie gardło przesunie się z wyszukiwania możliwości na szybkie udowodnienie, naprawienie i wdrożenie odpowiedzi wobec tych naprawdę istotnych.

Najważniejsza inwestycja: zdolność do weryfikacji

Sprint Bitcoin Red Team najlepiej rozumieć jako ostrzeżenie dotyczące przepustowości procesu bezpieczeństwa. Dzisiejsze ekosystemy potrafią szybko wygenerować tysiące wiarygodnych wskazówek. O ich odporności zdecyduje to, czy są w stanie finansować niezależne odtwarzanie błędów, bezpieczne kanały raportowania, czas opiekunów projektów, przeglądy kodu, testy i szybkie aktualizacje w porównywalnym tempie.

Dla projektów związanych z Bitcoinem kolejnym istotnym wskaźnikiem nie będzie więc rekordowa liczba zgłoszeń wygenerowanych przez AI. Będzie nim odsetek raportów, które zmienią się w potwierdzone podatności, odpowiedzialnie skoordynowane poprawki i wdrożone zabezpieczenia — zanim zadziałają atakujący. 1514