CVE-2026-55764
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 25 - wyżej niż 25% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko nieautoryzowanej emisji tokenów i naruszenia integralności łańcucha bloków.
Rekomendacja
Zaktualizuj Klever-Go do wersji 1.7.19. Ogranicz zaufanie do posiadaczy roli mint.
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-82407Wysokie
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.
- 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-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.19, Klever-Go allows a mint-role holder to bypass a finite per-nonce MaxSupply on the semi-fungible token add-quantity path. In core/kapp/systemAccount/systemAcount.go, SFTAddCirculation performed meta.Circulation += amount before evaluating whether Circulation exceeded MaxSupply, without checking for signed int64 overflow. A large positive raw Amount supplied through processSemiFungibleAddQuantity in core/kapp/kda/mint.go can wrap Circulation negative, causing the signed maximum-supply comparison to pass and crediting approximately MaxInt64 units while corrupting the on-chain counter. The fungible path is not affected because its MintedValue <= 0 guard detects the overflow. The correction uses the consensus activation flag FixMarketBuyOverflow. This issue is fixed in version 1.7.19.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

