CVE-2026-46403
ŚrednieCVSS 6.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 27 - wyżej niż 27% wszystkich znanych CVE
Streszczenie
Podatność w Klever-Go (implementacja protokołu blockchain Klever) przed wersją 1.7.17. Tryb tylko do odczytu (read-only) nie był wymuszany w ścieżkach usuwania i aktualizacji kontraktów, co pozwalało kontraktom wywołanym w trybie tylko do odczytu na modyfikację stanu łańcucha.
Ocena ryzyka
Ryzyko polega na naruszeniu izolacji między operacjami tylko do odczytu a modyfikującymi stan, co może prowadzić do nieautoryzowanych zmian w blockchainie.
Rekomendacja
Zaktualizuj Klever-Go do wersji 1.7.17 lub nowszej. Ogranicz dostęp do funkcji ExecuteReadOnlyWithTypedArguments tylko dla zaufanych kontraktów.
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-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.
- CVE-2026-52879Wysokie
Klever-Go w wersjach 1.7.14 do 1.7.17 jest podatny na zdalnie wyzwalany atak DoS przez nieograniczone tworzenie gorutyn. Obsługa bezpośrednich wiadomości tworzy nową gorutynę dla każdej wiadomości przed sprawdzeniem antiflood, co pozwala pojedynczemu peerowi na wysłanie strumienia wiadomości i przeciążenie węzła.
- CVE-2026-52878Wysokie
Klever-Go w wersjach 1.7.14 do 1.7.17 jest podatny na panikę z powodu nil-wskaźnika wywołaną przez transakcję protobuf z pominiętym polem RawData. Brak sprawdzenia nil przed dereferencją tx.RawData.Version w txVersionChecker.CheckTxVersion powoduje crash całego procesu węzła, co może doprowadzić do zatrzymania łańcucha.
- CVE-2026-49343Średnie
Klever-Go, implementacja protokołu blockchain Klever w Go, w wersjach przed 1.7.18 ma podatność na wyczerpanie zasobów w synchronizatorach trie danych konta. Błędy w ścieżkach błędów powodują trwałe zużycie slotów throttlera, co może doprowadzić do zatrzymania synchronizacji i awarii bootstrapu. Poprawka w wersji 1.7.18.
- CVE-2026-47249Wysokie
Klever-Go przed wersją 1.7.18 jest podatny na amplifikację tablicy skrótów w logice obsługi żądań P2P resolvera. Małe skompresowane żądanie (442 bajty) może rozwinąć się do 200 000 wpisów skrótów, powodując zdalną amplifikację pamięci i CPU.
- CVE-2026-58262Wysokie
Klever-Go przed wersją 1.7.20 ma podatność w weryfikacji podpisu nagłówka, gdzie nieużywane bity dopełnienia PubKeysBitmap są liczone do kworum dwóch trzecich walidatorów. Złośliwy producent bloków może ustawić te bity, aby osiągnąć wymagane kworum bez prawdziwej liczby podpisów, osłabiając bezpieczeństwo konsensusu.
Oryginalny opis (angielski, źródło NVD)
Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.17, KVM exposes `ExecuteReadOnlyWithTypedArguments` as a read-only execution mechanism. The hook saves the previous read-only state, sets `runtime.SetReadOnly(true)`, executes the destination context, and then restores the previous read-only state. However, the indirect contract delete and upgrade paths do not reject execution when `runtime.ReadOnly()` is true. As a result, a contract reached through read-only execution can call the production delete hook for a target contract it owns. The delete path appends the target address to `vmOutput.DeletedAccounts`, the output context merges `DeletedAccounts` into the caller output, and the smart contract processor later processes the VM output by deleting accounts listed in that field. The root cause is that read-only mode is applied as runtime state, but not enforced by the state-changing delete and upgrade host-core paths. This breaks the expected isolation boundary for workflows that rely on read-only calls to inspect another contract without allowing that callee to produce state-changing VM output. The issue is fixed in v1.7.17. Contract delete and upgrade host-core paths now reject execution when `runtime.ReadOnly()` is true. The invariant is regression-tested for delete, upgrade, storage writes, value transfers, and any VM output field that can later mutate chain state.