CVE-2026-55763: Klever klever-go percentage-transfer royalty zero-debit in accountsKapp

CVE-2026-55763 · Severity: high · CVSS 4 · Published 2026-08-28

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.

Technologies: github.com/klever-io/klever-go (Go). Vendors: Go.

Quick answers

Is CVE-2026-55763 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-55763 being exploited in the wild.
How severe is CVE-2026-55763?
High severity, with a CVSS score of 4, published 28 August 2026.
Which products and versions are affected?
github.com/klever-io/klever-go (Go) <= 1.7.19-rc2, SEMVER:introduced=0, SEMVER:introduced=0,fixed=1.7.19-rc4; Klever <= 1.7.19-rc2.
Is there a fix for CVE-2026-55763?
Yes. github.com/klever-io/klever-go (Go): upgrade to 1.7.19-rc4 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-55763 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-55763?
Check whether you run github.com/klever-io/klever-go (Go) or Klever at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • github.com/klever-io/klever-go (Go): upgrade to 1.7.19-rc4 or later
    go get github.com/klever-io/klever-go@v1.7.19-rc4

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

Identifiers

  • CVE-2026-55763
  • GHSA-v358-wf77-39xv
  • GO-2026-6323

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)

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.