CVE-2026-58262

Klever-Go before version 1.7.19 has a vulnerability in decoding split-royalty fields that can contain values greater than core.HundredPercent, and summing in uint32 accumulators can wrap the validation sum to zero and bypass checks. Royalty payout paths credit each oversized split amount and silently discard a negative remainder, allowing ordinary transfers to create unbacked KLV or other assets. This issue is fixed in version 1.7.19.

Klever-Go before version 1.7.19 has a vulnerability in marketplace settlement where it reads MarketOrderData.ReferralPercentage from the listing while reading asset.Royalties.MarketPercentage live at purchase time. An asset owner can create a valid listing and then use AssetTrigger UpdateRoyalties to make the combined percentages exceed the bid. executeBuyMarket pays referral and royalty amounts unconditionally while computeMarketOwnerAmount silently skips a nonpositive seller remainder, allowing more currency to be credited than paid. This issue is fixed in version 1.7.19.

Vulnerability in Klever-Go (Klever blockchain implementation) before version 1.7.19. A mint-role holder can bypass the finite MaxSupply on semi-fungible tokens via integer overflow, crediting a huge amount and corrupting the on-chain counter. Fixed in version 1.7.19.

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go calls SubFromBalance after the split loop and after the royaltiesToPay <= 0 early return. computeSplitRoyalties rejects only when splitToPay > royaltiesToPay, so a valid PercentTransferPercentage = 10000 split consumes exactly 100 percent of the royalty pool, sets royaltiesToPay to zero, and returns before the source account is debited. The split recipient receives the full royaltyAmount while the sender pays nothing and the supply counter is not updated, allowing unbounded off-the-books inflation of the transferred KDA. A KDA owner must configure a TransferPercentage royalty with a 100 percent split, after which any holder's transfer of the asset triggers the mint; the sibling processFixedRoyaltiesTransfer path is not affected because it debits the source before distribution. This issue is fixed in version 1.7.19.

Klever-Go, the Go implementation of the Klever blockchain protocol, versions 1.7.14 through 1.7.17 are vulnerable to a remotely triggerable denial of service. REST APIs are started with the default Go HTTP server without ReadHeaderTimeout, ReadTimeout, or MaxHeaderBytes configured, allowing connections to be held open indefinitely, exhausting file descriptors.

Klever-Go versions 1.7.14 through 1.7.17 are vulnerable to a remotely triggerable denial of service via unbounded goroutine creation. The direct-message ingress handler spawns a goroutine for every message before antiflood checks, allowing a single peer to send a stream of messages and overload the node.

Klever-Go versions 1.7.14 through 1.7.17 are vulnerable to a nil-pointer panic triggered by a protobuf Transaction with omitted RawData sub-message. The lack of nil check before dereferencing tx.RawData.Version in txVersionChecker.CheckTxVersion causes a crash of the entire node process, potentially leading to a chain halt.

Klever-Go, the Go implementation of the Klever blockchain protocol, versions prior to 1.7.18 have a resource-exhaustion flaw in account-data trie syncers. Errors on error paths permanently consume throttler slots, potentially causing sync to stop and bootstrap to fail. Fixed in version 1.7.18.

Klever-Go prior to version 1.7.18 is vulnerable to hash-array amplification in the P2P resolver request handling logic. A small compressed request (442 bytes) can expand into 200,000 decoded hash entries, causing remote memory and CPU amplification.

Vulnerability in Klever-Go (Go implementation of the Klever blockchain protocol) before version 1.7.17. Read-only mode was not enforced in contract delete and upgrade paths, allowing contracts called in read-only mode to mutate chain state.