CVE-2026-82750

W bibliotece ZenHive mpp (od 0.14.0 do 0.16.2) występuje nieprawidłowa walidacja ilości w danych wejściowych. Klient posiadający otwarty kanał płatności może uzyskać płatne zasoby bez naliczenia opłat, ponieważ voucher o tej samej skumulowanej kwocie jest traktowany jako idempotentny sukces i nie jest wywoływana funkcja maybe_spend/2. Ten sam podpisany voucher można wielokrotnie przedstawiać pod nowymi wyzwaniami, uzyskując nieograniczoną liczbę opłaconych jednostek.

W bibliotece ZenHive mpp (od 0.14.0 do 0.16.2) występuje obejście uwierzytelniania przez atak typu capture-replay. Atakujący posiadający przechwycony poświadczenie aktywacji subskrypcji może wielokrotnie obciążać płatnika, ponieważ podpisana autoryzacja nie jest powiązana z konkretnym wyzwaniem, a deduplikacja aktywacji odbywa się po identyfikatorze wyzwania. Każde odtworzenie powoduje nowe rozliczenie pierwszego okresu i ponowną autoryzację klucza serwera.

Nieprawidłowa walidacja ilości w ZenHive mpp pozwala nieuwierzytelnionemu zdalnemu klientowi zawyżyć koszt gazu płatnika za sponsorowaną płatność oraz sprawić, że sponsor zapłaci za utworzenie klucza dostępu na koncie klienta. Brak sprawdzenia pola key_authorization w kopercie 0x76 umożliwia dołączenie podpisanego klucza, co zwiększa koszt z ok. 46 587 do ok. 1 808 700 gazu.

Podatność typu Time-of-check Time-of-use (TOCTOU) w ZenHive mpp umożliwia nieuwierzytelnionemu zdalnemu klientowi wykorzystanie jednej potwierdzonej płatności on-chain do wielokrotnego dostępu do płatnych zasobów. Ścieżka uwierzytelniania typu "hash" w MPP.Methods.Tempo.verify/2 chroni przed powtórzeniem za pomocą nieatomowej sekwencji sprawdź-oznacz: check_hash_unused/2 odczytuje magazyn deduplikacji, eth_getTransactionReceipt weryfikuje płatność w łańcuchu, a dopiero potem mark_hash_used/2 zapisuje znacznik. Równoczesne żądania z tym samym rozliczonym hashem płatności przechodzą przez odczyt, zanim którekolwiek zapisze, więc każde otrzymuje potwierdzenie. Magazyn posiada atomową prymitywę check_and_mark/2 używaną przez ścieżkę typu "transaction", ale ścieżka hash wywołuje zwykłe get i put nawet gdy skonfigurowany magazyn ją implementuje. Wykorzystanie wymaga skonfigurowania magazynu deduplikacji; domyślny magazyn nil jest bezstanowy i udokumentowany jako nieoferujący żadnej ochrony przed powtórzeniem. Problem dotyczy mpp od 0.2.0 przed 0.6.1.

ZenHive mpp zawiera podatność polegającą na alokacji zasobów bez limitów lub ograniczania, która pozwala nieuwierzytelnionemu zdalnemu klientowi na wyczerpanie portfela opłat poprzez równoczesne sponsorowane płatności, co prowadzi do odmowy usługi dla legalnych płatników po jego opróżnieniu. Polityka opłat egzekwuje limity tylko dla pojedynczej transakcji, a nie dla równoczesnych żądań.

ZenHive mpp zawiera podatność polegającą na obejściu uwierzytelnienia przez przechwycenie i powtórzenie, która pozwala nieuwierzytelnionej trzeciej stronie na uzyskanie płatnych zasobów poprzez powtórzenie transferu rozliczonego przez niezwiązanego płatnika. Gdy skonfigurowany jest statyczny 'memo', weryfikacja powiązania jest pomijana, a atakujący może użyć publicznego transferu jako poświadczenia.

Podatność w ZenHive mpp umożliwia nieuwierzytelnionemu zdalnemu klientowi uzyskanie płatnych zasobów poprzez ponowne przesłanie jednego rozliczonego transferu on-chain. Mechanizm weryfikacji EVM nie wiąże dowodu z wyzwaniem ani z wcześniejszym użyciem, a klucze deduplikacji są regenerowane przy każdym błędzie 402. Na trasie ze stałą ceną pojedynczy historyczny transfer spełnia wymagania nieograniczonej liczby późniejszych opłat.