CVE-2026-104424

Zebra w wersji przed 4.4.0 zawiera podatność rozbieżności konsensusu w weryfikacji przezroczystych sygnatur V5, obliczając skrót ZIP-244 dla wejść SIGHASH_SINGLE bez odpowiadających wyjść zamiast zgłosić błąd. Atakujący może tworzyć transakcje V5 z mniejszą liczbą wyjść niż wejść, które Zebra akceptuje i szablonuje przez getblocktemplate, produkując bloki odrzucane przez zcashd.

Zebra przed wersją 4.5.0 zawiera podatność niekontrolowanego zużycia zasobów, która pozwala zdalnym rówieśnikom P2P wyczerpać wątki puli blokującej poprzez wysyłanie nadmiernie dużych wektorów lokalizatorów bloków. Atakujący mogą wysyłać wiadomości getblocks lub getheaders z maksymalnie 65 535 haszami lokalizatorów, co powoduje wyszukiwania łańcucha dla każdego hasza i pogarsza wydajność walidacji bloków, RPC i mempool.

Zebra zebrad 4.4.0 i zebra-script 6.0.0 nie egzekwują reguły konsensusu ZIP-244, akceptując przezroczyste wejścia V5 podpisane z SIGHASH_SINGLE, które nie mają odpowiadającego wyjścia. Atakujący może rozgłaszać spreparowane transakcje V5 z większą liczbą wejść niż wyjść, które Zebra akceptuje, ale zcashd odrzuca, powodując rozdzielenie konsensusu sieci.

ZcashFoundation Zebra zebra-rpc w wersjach przed 8.0.0 i zebrad przed 4.5.0 zawierają osiągalne asercje w handlerze RPC z_listunifiedreceivers, który wywołuje expect() przy parsowaniu odbiorcy Sapling, co kończy się niepowodzeniem dla Unified Addresses zawierających nieprawidłowe punkty Jubjub. Uwierzytelnieni klienci RPC mogą przesłać taki adres, aby przerwać proces zebrad, wielokrotnie utrzymując węzeł offline.

Zebra przed wersją 6.3.0 zawiera nieprawidłową obsługę wyjątkowych warunków w funkcji ChainSync::obtain_tips, która odrzuca poprawne odpowiedzi FindBlocks z jednym hashem, fałszywie zgłaszając status blisko szczytu. Peery zwracające tylko następny hash bloku powodują zerową próbkę synchronizacji, przez co punkt końcowy /ready zwraca 200 OK, podczas gdy węzeł pozostaje w tyle za szczytem.

Zebra w wersji przed 6.0.0 zawiera podatność typu denial of service, która pozwala nieuwierzytelnionym peеrом blokować wątki Tokio poprzez przesyłanie transakcji do mempoola wymagających kosztownej synchronicznej weryfikacji skryptów. Atakujący może wysyłać niestandardowe transakcje P2SH o wysokiej liczbie sigop, które docierają do CachedFfiTransaction::is_valid() przed sprawdzeniami standardowości, nasycając bufor weryfikatora i czyniąc węzeł nieodpowiadającym.

Zebra zebrad 4.5.0 i zebra-script 7.0.0 liczą operacje podpisu skryptu redeem P2SH w trybie legacy zamiast dokładnego trybu P2SH zcashd, przeliczając CHECKMULTISIG poprzedzony OP_1 do OP_16 jako 20 sigopów i powodując rozbieżność konsensusu. Zdalni atakujący mogą rozgłaszać wydatki P2SH używające skryptów redeem multisig o niskim progu, tak że blok akceptowany przez zcashd przekracza zawyżony licznik MAX_BLOCK_SIGOPS Zebry, powodując odrzucenie go przez węzły Zebra i zatrzymanie ich poza łańcuchem.

Zebra (zebrad) w wersjach od 5.0.0 do przed 6.0.0-rc.0 nie stosuje limitu przyjęć mempool na peer do transakcji otrzymywanych jako bezpośrednie wiadomości P2P tx, ponieważ są one kolejkowane bez zapisania wysyłającego peera jako źródła. Zdalny przychodzący peer może wysłać wiele unikalnych transakcji, zajmując nieproporcjonalną część miejsc przyjęć mempool, wypierając uczciwe przekaźniki transakcji innych peerów.

Zebra przed wersją 6.1.0 zawiera podatność niepełnego czyszczenia w zadaniu zapisu stanu, która pozwala zdalnym nieuwierzytelnionym peerom na zatrzymanie synchronizacji węzła poprzez zatrucie parent_error_map. Atakujący mogą dostarczyć blok z manipulowanym coinbase, który ma ten sam hash co kanoniczny blok, zanim ten się rozprzestrzeni, powodując odrzucenie następnego kanonicznego bloku i zatrzymanie węzła na około 2000 bloków.

Zebra przed wersją 6.1.0 zawiera podatność nieefektywnej złożoności algorytmicznej w funkcji remaining_transaction_value, która klonuje całą mapę wydanych UTXO na poziomie bloku dla każdej transakcji podczas weryfikacji kontekstowej. Atakujący mogą wydobyć lub zasiać mempool około 26 000 minimalnych transakcji z jednym wejściem w jednym bloku, zatrzymując każdy walidujący węzeł na ponad 52 sekundy.