CVE-2026-52737

W Zebra przed wersją 6.4.0 wykryto podatność polegającą na nieprawidłowej walidacji integralności w ścieżce pobierania przychodzących danych gossip. Pozwala ona nieuwierzytelnionym peerom na wymuszenie odrzucania nowych bloków bez kary. Atakujący mogą dostarczyć prawdziwy blok z przepisanym scriptSig coinbase na wysokość 1, co zachowuje hash bloku ZIP-244, powodując odrzucenie bloku przed walidacją konsensusu i opóźniając odkrycie tipu dla backendów wydobywczych.

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 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ść 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.

ZcashFoundation Zebra przed wersją 6.1.0 zawiera podatność wyczerpania zasobów, która pozwala nieuwierzytelnionym peerom na degradację przetwarzania bloków poprzez wysyłanie transakcji z nieprawidłowymi dowodami Orchard bez otrzymania punktów kar. Atakujący mogą wielokrotnie wysyłać nieprawidłowe dowody do wspólnego weryfikatora halo2, zmuszając uczciwe dowody bloków do wolnej ścieżki indywidualnej weryfikacji i spowalniając przetwarzanie bloków około siedmiokrotnie.

Zebra (zebrad) w wersji przed 6.2.1 zawiera asymetryczną podatność zużycia zasobów, która pozwala nieuwierzytelnionym peеrом blokować weryfikację bloków poprzez przesyłanie transakcji V6 do mempoola z nieprawidłowymi dowodami Halo2. Atakujący może zalać współdzieloną kolejkę weryfikacji Halo2 bez priorytetu transakcjami o zerowej opłacie z wypełnionymi zerami dowodami Orchard i Ironwood, powodując opóźnienie węzłów względem końca łańcucha.