Firma CertiK, zajmująca się bezpieczeństwem Web3, wykryła poważną podatność typu out-of-bounds (OOB) write w portfelu sprzętowym BitBox02. Luka, odkryta przez badacza CertiK Guanxinga Wena, otwierała drogę do potencjalnego przejęcia kontroli nad przepływem wykonania programu (control-flow hijacking) za pomocą zmanipulowanych poleceń USB. Ustalenie to podkreśla narastającą obawę w przestrzeni aktywów cyfrowych: samo przechowywanie kluczy prywatnych w trybie offline nie wystarcza już samo w sobie, by zagwarantować całkowite bezpieczeństwo aktywów.

Jak działała luka w BitBox02

Portfele sprzętowe są zaprojektowane tak, aby klucze prywatne nie trafiały na urządzenia podłączone do internetu, jednak każda transakcja nadal rozpoczyna się poza portfelem. Urządzenie musi odebrać polecenia, przeanalizować dane, wyświetlić szczegóły potwierdzenia i wygenerować podpis.

Jak BitBox publicznie ujawnił w swojej lipcowej aktualizacji bezpieczeństwa Oeschinen, tajne klucze prywatne przechowywane wewnątrz portfela nigdy nie zostały bezpośrednio ujawnione. Problem polegał natomiast na sposobie, w jaki urządzenie komunikowało się z komputerem.

Podczas odbierania poleceń przez USB oprogramowanie portfela bezkrytycznie przyjmowało instrukcje określające, ile danych nadchodzi, nie sprawdzając, czy zmieszczą się one w tymczasowej przestrzeni pamięciowej urządzenia. Atakujący mógł to wykorzystać, wysyłając nadmiarowo duże polecenie w celu przepełnienia bufora pamięci, co — jak wskazał BitBox — mogło pozwolić mu na przejęcie kontroli nad urządzeniem. W praktyce zapis poza zakresem (out-of-bounds write) to klasyczny błąd bezpieczeństwa pamięci: dane przelewają się poza koniec przydzielonego bufora i nadpisują sąsiednią pamięć, a przy wystarczającej kontroli nad tymi danymi atakujący może przekierować wykonywanie programu urządzenia — czyli dokładnie control-flow hijacking, przed którym ostrzegał BitBox. Wykorzystanie luki wymagałoby dostarczenia portfelowi złośliwych poleceń USB, i właśnie dlatego CertiK podkreślał, że podłączony komputer lub smartfon należy zawsze traktować jako źródło niezaufanych danych wejściowych, co oznacza, że firmware portfela musi bezpiecznie przetwarzać każde otrzymane polecenie. Poprawka została włączona do lipcowej aktualizacji BitBox.

Szerszy wzorzec w bezpieczeństwie portfeli sprzętowych

Przypadek BitBox02 nie jest odosobniony. Na początku 2026 roku Ledger załatał lukę w bootloaderze MCU (CVE-2025-15645) po tym, jak CertiK wykrył, że procedury obsługi resetu przekazywane przez hosta nie były odpowiednio walidowane podczas aktualizacji firmware'u. Luka dotyczyła procesu aktualizacji firmware'u MCU Ledgera, w którym bootloader — niewielki fragment kodu inicjujący mikrokontroler urządzenia przed załadowaniem głównego firmware'u — nie w wystarczającym stopniu weryfikował dostarczony przez hosta adres reset_handler. Ledger usunął problem i oświadczył, że środki użytkowników nigdy nie były zagrożone.

Oba przypadki łączy wspólny wątek: każdy z portfeli ufał danym pochodzącym ze źródła zewnętrznego — w jednym przypadku poleceniu USB, w drugim danym wejściowym aktualizacji firmware — bez ich wystarczającej walidacji.

Stawka dla bezpieczeństwa Web3 rzadko była wyższa. Zgodnie z raportem Hack3D H1 2026 firmy CertiK, w pierwszej połowie 2026 roku 344 incydenty bezpieczeństwa spowodowały łącznie ponad 1,31 miliarda dolarów strat w kryptowalutach. Kompromitacje portfeli okazały się najbardziej dotkliwym pojedynczym zagrożeniem, odpowiadając za straty ponad 444 milionów dolarów w zaledwie 33 osobnych atakach.

Na tym tle — wobec tego, że kompromitacje portfeli należą obecnie do najkosztowniejszych kategorii ataków w Web3 — przypadek BitBox02 pokazuje, że bezpieczeństwo portfeli sprzętowych zależy od czegoś więcej niż tylko izolacja kluczy prywatnych: firmware, protokoły komunikacyjne i procesy potwierdzania muszą również być odporne na niezaufane dane wejściowe. Dla właścicieli BitBox02 praktyczny następny krok jest prosty: zainstalowanie lipcowej aktualizacji Oeschinen, aby na urządzeniu działał załatany firmware.