CVE-2026-82407
WysokieCVSS 7.0Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 35 - wyżej niż 35% wszystkich znanych CVE
Streszczenie
Klever-Go przed wersją 1.7.20 w core/kapp/validators/validators.go Register oraz ścieżka aktualizacji walidatora w czasie działania akceptują przesłany BLSPublicKey bez walidacji krzywej, podgrupy pierwszego rzędu lub niezerowości. Gdy walidator z nieprawidłowym kluczem zostanie wybrany do grupy konsensusu, MultiSigner.Reset i ścieżka weryfikacji podpisu nie mogą zdeserializować klucza grupy i anulują slot.
Ocena ryzyka
Powoduje to powtarzające się pominięte rundy i degradację przepustowości, a sieć, której grupa konsensusu równa się zestawowi kwalifikujących się walidatorów, może całkowicie się zatrzymać.
Rekomendacja
Zaktualizuj Klever-Go do wersji 1.7.20 lub nowszej.
Inne podatności w Klever-Go
Zobacz wszystkie- CVE-2026-54755Krytyczne
Klever-Go przed wersją 1.7.19 zawiera podatność w dekodowaniu pól split-royalty, które mogą zawierać wartości większe niż core.HundredPercent, a sumowanie w akumulatorach uint32 może spowodować zawinięcie sumy do zera i ominięcie walidacji. Ścieżki wypłat royalty kredytują każdą nadmierną kwotę i po cichu odrzucają ujemną resztę, co pozwala na tworzenie niepokrytych aktywów KLV lub innych. Problem naprawiono w wersji 1.7.19.
- CVE-2026-54754Krytyczne
Klever-Go przed wersją 1.7.19 zawiera podatność w rozliczeniach rynkowych, gdzie odczytuje ReferralPercentage z oferty, a Royalties.MarketPercentage na żywo w momencie zakupu. Właściciel aktywa może utworzyć ważną ofertę, a następnie użyć AssetTrigger UpdateRoyalties, aby połączone wartości procentowe przekroczyły cenę oferty. Wykonanie zakupu płaci kwoty referral i royalty bezwarunkowo, podczas gdy computeMarketOwnerAmount pomija nieujemną resztę sprzedawcy, co pozwala na kredytowanie większej ilości waluty niż zapłacono. Problem naprawiono w wersji 1.7.19.
- CVE-2026-86065Wysokie
Klever-Go przed wersją 1.7.20 udostępnia domyślnie otwarty endpoint GET /subscribe, który akceptuje nieuwierzytelnionych klientów WebSocket, nie ogranicza rozmiaru wiadomości ani liczby połączeń. Pojedynczy klient może rozrastać mapy subskrypcji, a wielu klientów może zatrzymywać goroutines, bufory i deskryptory, co prowadzi do wyczerpania pamięci lub zasobów i awarii węzła.
- CVE-2026-86064Wysokie
Klever-Go przed wersją 1.7.20 udostępnia domyślnie otwartą trasę WebSocket GET /log, która nie wymaga uwierzytelnienia. Pierwsza wiadomość klienta jest przetwarzana jako profil loggera i stosowana globalnie, co pozwala zdalnemu klientowi zmieniać globalne poziomy logowania i formatowanie oraz odbierać logi procesu.
- CVE-2026-82409Wysokie
Klever-Go przed wersją 1.7.20 w indexer/common.go umieszcza kontrolowaną przez atakującego wartość acc.Name w żądaniu _bulk JSON i NDJSON do Elasticsearch bez escapowania. Transakcja SetAccountName akceptuje prawidłowe nazwy kont UTF-8 zawierające cudzysłowy, ukośniki odwrotne i znaki nowej linii, które mogą uszkodzić ciąg JSON, odrzucić partię lub wstrzyknąć dodatkowe akcje bulk.
- CVE-2026-82406Wysokie
W bibliotece Klever-Go przed wersją 1.7.20 funkcja Buy w module marketplace nie sprawdza flagi IsClaimed przed przyjęciem oferty. Sprzedawca może rozliczyć aukcję z ofertą oczekującą, pozostawiając zamówienie z przyszłym EndTime oraz nieaktualnymi wartościami CurrentBid i CurrentBidder. Kolejny licytujący może złożyć wyższą ofertę, zostać obciążony, a poprzedni licytujący otrzymuje zwrot, mimo że NFT zostało już dostarczone.
- CVE-2026-82405Wysokie
W Klever-Go przed wersją 1.7.20 wbudowana funkcja KleverUpdateAccountPermission autoryzuje zmianę uprawnień konta docelowego, sprawdzając kontrolowane przez atakującego vmInput.RecipientAddr zamiast uwierzytelnionego vmInput.CallerAddr. Kontrakt atakującego może wybrać konto ofiary z skonfigurowanymi uprawnieniami jako RecipientAddr, a contractHasValidPermission może zaakceptować domyślnego self-signera ofiary jako autoryzację. UpdatePermission może następnie zastąpić cały zestaw uprawnień ofiary uprawnieniami Owner dostarczonymi przez atakującego, umożliwiając kradzież zasobów lub trwałe zablokowanie konta bez klucza lub podpisu ofiary.
- CVE-2026-55764Wysokie
Podatność w Klever-Go (implementacja blockchain Klever) przed wersją 1.7.19. Posiadacz roli mint może obejść limit MaxSupply dla tokenów semi-fungible, wykorzystując przepełnienie licznika, co prowadzi do zakredytowania ogromnej ilości jednostek i uszkodzenia licznika w łańcuchu. Poprawka dostępna w wersji 1.7.19.
- CVE-2026-55763Wysokie
Klever-Go to implementacja protokołu blockchain Klever w języku Go. Przed wersją 1.7.19 funkcja processPercentageRoyaltiesTransfer w core/kapp/accounts/accounts.go wywołuje SubFromBalance po pętli podziału i po wczesnym powrocie, gdy royaltiesToPay <= 0. computeSplitRoyalties odrzuca tylko wtedy, gdy splitToPay > royaltiesToPay, więc prawidłowy podział PercentTransferPercentage = 10000 zużywa dokładnie 100 procent puli tantiem, ustawia royaltiesToPay na zero i zwraca przed obciążeniem konta źródłowego. Odbiorca podziału otrzymuje pełną kwotę tantiem, podczas gdy nadawca nic nie płaci, a licznik podaży nie jest aktualizowany, co pozwala na nieograniczoną inflację transferowanego KDA poza księgami. Właściciel KDA musi skonfigurować tantiemę TransferPercentage z 100-procentowym podziałem, po czym każdy transfer zasobu przez posiadacza wyzwala bicie; ścieżka processFixedRoyaltiesTransfer nie jest dotknięta, ponieważ obciąża źródło przed dystrybucją. Problem jest naprawiony w wersji 1.7.19.
- CVE-2026-52880Wysokie
Klever-Go, implementacja protokołu blockchain Klever w Go, w wersjach od 1.7.14 do 1.7.17 jest podatna na zdalnie wyzwalany atak DoS. Serwery REST są uruchamiane z domyślnym serwerem HTTP Go bez skonfigurowanych limitów (ReadHeaderTimeout, ReadTimeout, MaxHeaderBytes), co pozwala na trzymanie połączeń otwartych w nieskończoność, prowadząc do wyczerpania deskryptorów plików.
Oryginalny opis (angielski, źródło NVD)
Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.20, core/kapp/validators/validators.go Register and the runtime validator update path accept a submitted BLSPublicKey without curve, prime-order subgroup, or nonzero validation. When a validator with a malformed key becomes eligible and is selected into a consensus group, MultiSigner.Reset and the corresponding signature verification creation path cannot deserialize the group key and cancel the slot. This causes repeated missed rounds and throughput degradation, and a network whose consensus group equals the eligible validator set can halt completely. Genesis validation is not affected because that path already performs CheckPublicKeyValid. This issue is fixed in version 1.7.20.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

