Katalog CVE

CVE-2026-88255

ŚrednieCVSS 6.3
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.39%

Percentyl 33 - wyżej niż 33% wszystkich znanych CVE

Streszczenie

W ZenHive mpp przed wersją 0.16.2, nieprawidłowa walidacja równoważności w danych wejściowych pozwala nieuwierzytelnionemu zdalnemu klientowi przejść bramę duplikatów Tempo dwukrotnie z jednym podpisanym transakcją. MPP.Methods.Tempo rezerwuje slot deduplikacji na podstawie hex dostarczonego przez wywołującego, a nie kanonicznej formy transakcji, co pozwala na dwa różne klucze rezerwacji dla tej samej transakcji (np. v=27 i v=0). W rezultacie oba przechodzą rezerwację i trafiają do ścieżki broadcast, a węzeł może zwrócić drugi ważny Payment-Receipt za jedną płatność on-chain.

Ocena ryzyka

Atakujący może uzyskać wiele potwierdzeń płatności za jedną transakcję, co może prowadzić do oszustw finansowych lub naruszenia integralności systemu płatności.

Rekomendacja

Zaktualizuj mpp do wersji 0.16.2 lub nowszej. Monitoruj transakcje pod kątem duplikatów i rozważ dodatkowe mechanizmy walidacji kanonicznej formy transakcji.

Inne podatności w mpp

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

Improper Validation of Unsafe Equivalence in Input in ZenHive mpp allows an unauthenticated remote client to pass the Tempo duplicate-submission gate twice with one signed transaction. MPP.Methods.Tempo reserves the pre-broadcast dedup slot on the caller-supplied hex in reserve_hash_atomic/2, keyed through store_key/1 on tx.raw rather than on a canonical form of the transaction. The deserializer stores the caller's hex verbatim and accepts both recovery-id encodings, so one signed transaction submitted once with v=27 and once with v=0 yields two distinct reserve keys, and both pass the reserve and reach the broadcast path. The plug-level credential replay store is deliberately carved out for tempo in lib/mpp/replay.ex, leaving this reserve as the only gate, and the post-broadcast mark writes the canonical hash key that the raw-keyed reserve never reads. What the duplicate submission yields depends on the node: a nonce-reuse rejection fails closed, while a node that answers with the canonical hash for an already-known transaction returns a second valid Payment-Receipt for a single on-chain payment. This issue affects mpp: from 0.2.0 before 0.16.2.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS