← Blog · · df00tech

Klever Node Bug Let Attackers Mint Unlimited KLV via Integer Overflow in Royalty Splits

breaking ghsa go CVE-2026-54755

A newly disclosed GitHub Security Advisory (GHSA-cgc5-v3f2-8m2v, tracked as CVE-2026-54755, CVSS 9.6) details a critical flaw in klever-io/klever-go, the node software for the Klever blockchain. According to the advisory, split-royalty percentages on a KDA (Klever Digital Asset) are validated by summing per-entry values into a uint32 accumulator and checking only the total against a 10000 (100%) ceiling — with no bound on any individual entry. Two entries whose values sum to just over 2^32 wrap around to a small number, passing validation while each stored value remains enormous. At payout time, each split recipient is credited pool × hugePct / 10000, far exceeding the actual royalty pool, and the resulting negative remainder is silently discarded rather than rejected.

Because fixed royalties (and marketplace/ITO royalties) are denominated in KLV, the native token, this lets an attacker mint KLV out of thin air by creating a throwaway asset with two crafted split-royalty entries and then transferring or selling it. The advisory states the bug is not gated by any fork/activation flag and is exploitable on current mainnet, and includes a working proof-of-concept showing 429,496.73 KLV minted from a single transfer that only cost 1 KLV in nominal fixed royalty. Notably, the minted value does not appear in the asset's tracked circulating supply, since it is issued via direct balance credit rather than a tracked mint operation — making the inflation invisible to standard supply dashboards.

Why It Matters

This is a direct threat to the economic integrity of the Klever chain: any account able to pay ordinary transaction fees can repeatedly and deterministically inflate the KLV supply, with no special privileges, roles, or allowlisting required. The advisory also notes the same root cause affects the transfer-percentage path (minting the transferred asset itself) and marketplace/ITO buy flows (minting KLV or the sale currency). Because the mint bypasses the chain's normal supply-tracking bookkeeping, exchanges, custodians, and anyone accounting for KLV balances or asset supply could be affected without an obvious on-chain signal in aggregate supply figures.

What Defenders Should Watch For

  • Node operators and infrastructure teams running klever-io/klever-go should treat this as urgent and apply whatever patched release or mitigation the Klever team issues, given the advisory states this is exploitable on current mainnet with no fork-flag gating.
  • Exchanges, custodians, and services that credit or debit KLV balances based on on-chain transfers should be alert to anomalously large KLV transfer amounts relative to the nominal royalty or transaction context, particularly transfers immediately following creation of a new, low-reputation KDA asset with split-royalty configurations.
  • Since booked circulating supply is not updated by this exploit path, supply dashboards alone are insufficient — teams with visibility into the chain should consider independently reconciling summed account balances against reported supply to catch discrepancies.
  • At a code level, the advisory's own remediation guidance is instructive for anyone auditing similar systems: never sum percentage-style values into a fixed-width integer without bounding each individual entry first, and never silently discard a negative remainder in a payout calculation — treat it as a hard validation error.

This is a same-day, developing item based on a newly published GitHub Security Advisory with a public proof-of-concept; the practical exposure (e.g., whether third parties have exploited it in the wild, and the status of any patch) may evolve. For full technical detail, including the vulnerable code paths and the advisory's proposed fix, see the original disclosure at GHSA-cgc5-v3f2-8m2v.

Get new detections in your inbox

New ATT&CK coverage plus CISA KEV / CVE detection rules, roughly weekly. No spam, unsubscribe anytime.