CVE-2026-46403

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.

Klever-Go prior to 1.7.20 exposes a default-open GET /subscribe endpoint that accepts unauthenticated WebSocket clients with permissive origin handling, no message size limit, and no live-connection cap. A single client can grow subscription maps, and many clients can retain goroutines, buffered channels, and descriptors, leading to memory or scheduler exhaustion.

Klever-Go prior to 1.7.20 exposes a default-open GET /log WebSocket route that does not require authentication. The first client message is parsed as a logger Profile and applied process-wide, allowing a remote client to change global log levels and formatting options and receive live process logs.

Klever-Go prior to 1.7.20 in indexer/common.go places the attacker-controlled acc.Name value into an Elasticsearch _bulk JSON and NDJSON request without escaping it. The SetAccountName transaction accepts valid UTF-8 account names containing quotes, backslashes, and newlines, which can break the JSON string, reject a bulk batch, or inject additional bulk actions.

Klever-Go prior to 1.7.20 in 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 is selected into a consensus group, MultiSigner.Reset and the signature verification creation path cannot deserialize the group key and cancel the slot.

In Klever-Go prior to version 1.7.20, the marketplace Buy function does not check IsClaimed before accepting a bid. A seller can settle a resting-bid auction via the Claim seller-accept branch, leaving the claimed order loadable with a future EndTime and stale CurrentBid and CurrentBidder values. A later bidder can submit a higher bid, be debited, and cause the previous bidder to receive a refund even though the NFT has already been delivered.

In Klever-Go prior to version 1.7.20, the KleverUpdateAccountPermission built-in authorizes replacement of a target account's permissions by checking attacker-controlled vmInput.RecipientAddr instead of authenticated vmInput.CallerAddr. An attacker-controlled contract can choose a victim account with configured permissions as RecipientAddr, and contractHasValidPermission can accept the victim's default self-signer as authorization. UpdatePermission can then replace the victim's entire permission set with attacker-supplied Owner permissions, enabling asset theft or permanent lockout without a victim key or signature.

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.