Executive brief
Klever-go is a blockchain node implementation for the Klever network that handles asset transfers and royalties. A vulnerability in the royalty distribution code allows asset owners to create an unbounded supply of their tokens at no cost. By configuring a "100% split" in a transfer royalty, the code credits recipients but skips debiting the sender—minting new tokens on every transfer. This can inflate token supplies without limit and is triggered automatically on any holder's transfer of the affected asset.
Technical details
The vulnerability is a logic-order bug in `core/kapp/accounts/accounts.go`, function `processPercentageRoyaltiesTransfer`. The royalty pool is computed and distributed in a split loop, then checked against a guard `if royaltiesToPay <= 0 { return Ok }` (which exits early if the remainder is zero), and only *after* this early-return is the sender debited via `acntSrc.SubFromBalance(royaltyAmount)`. The guard uses a strict inequality `splitToPay > royaltiesToPay`, so a split entry of exactly 100% (`PercentTransferPercentage = 10000`) is a valid configuration. At 100%, the first split allocation consumes the entire pool, leaving `royaltiesToPay = 0`, which triggers the early return *before* the sender is debited. The split recipient is already credited inside the loop, so they retain the full royalty amount while the sender pays nothing—a net token creation. The sibling fixed-royalty path `processFixedRoyaltiesTransfer` is safe because it debits the sender *before* the split loop. Reachability is owner-gated (asset owner must configure the split), but once configured, the mint fires on *any* holder's transfer. Proof-of-concept includes a Go unit test and live on-chain reproduction (asset F07-3NG3 with a 10% transfer royalty and single 100% split).
Affected products
- Klever klever-go <= 1.7.19-rc2
Timeline
- 2026-06-22: disclosed: Published in GitHub Advisory Database
- 2026-06-22: patched: Fixed in version 1.7.19-rc4
- 2026-08-28: other: Advisory published (GHSA-v358-wf77-39xv)