Description

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, marketplace settlement in core/kapp/market/market.go 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 referral and royalty percentages exceed the bid. executeBuyMarket pays referral and royalty amounts unconditionally while computeMarketOwnerAmount silently skips a nonpositive seller remainder, allowing MarketBuy, BuyItNow, or auction Claim settlement to credit more KLV or sale currency than the buyer paid. This can create unbacked currency and corrupt token supply integrity. This issue is fixed in version 1.7.19.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-08-28T20:18:17.533Z",
  "pubdate": "2026-08-28T20:18:17.533Z",
  "executiveSummary": "The Klever-Go blockchain protocol is susceptible to a critical state consistency vulnerability affecting marketplace settlements in versions prior to 1.7.19. The issue arises from a discrepancy in how referral percentages and royalty percentages are calculated during a purchase lifecycle.\nSpecifically, the system reads ReferralPercentage from the original listing data while fetching the asset's MarketPercentage from live storage at the moment of execution. An attacker can manipulate these parameters using the AssetTrigger UpdateRoyalties function to increase total fees beyond the buyer's bid amount.\nThis imbalance allows for the creation of unbacked currency, as the system unconditionally executes payments for royalties and referrals even when the combined total exceeds the purchase price. By exploiting this logic, an attacker can drain market liquidity or inflate token supply, leading to systemic corruption of the asset's value and integrity. The vulnerability requires an asset owner to possess the ability to update royalty settings post-listing, making it an authenticated, logic-based attack that does not require low-level memory corruption.",
  "technicalDetails": "The vulnerability resides in the core/kapp/market/market.go file within the Klever-Go implementation, specifically within the settlement logic of the marketplace module. The root cause is an insecure temporal decoupling between the listing state and the live asset state during transaction execution.\nIn the vulnerable versions, the market order process relies on static data for referral fees, specifically MarketOrderData.ReferralPercentage, which is captured when the asset is initially listed. Conversely, the royalty fees are fetched dynamically via asset.Royalties.MarketPercentage at the time the buy order is processed. Because the protocol does not enforce a synchronous validation between these two values at the time of purchase, a race condition or state-manipulation vulnerability exists.\nThe attack flow follows a precise sequence: 1) The attacker lists an asset for sale, capturing a specific referral percentage. 2) Before the purchase is executed, the attacker utilizes the AssetTrigger UpdateRoyalties function to modify the live royalty percentage for the asset. 3) The attacker or a colluding party triggers a purchase (via MarketBuy, BuyItNow, or auction claim). 4) The executeBuyMarket function processes the transaction by paying out the calculated referral and royalty amounts unconditionally based on the manipulated live state.\nBecause the logic in computeMarketOwnerAmount silently handles nonpositive seller remainders by skipping the seller payment rather than reverting the transaction or capping the fees, the system permits a state where the sum of fees (Referral + Royalty) exceeds the bid amount provided by the buyer. This results in the creation of unbacked KLV or sale currency, as the protocol mints or distributes funds beyond the actual buyer's payment. The lack of an upper-bound check against the purchase price ensures that the sum of these payments is not constrained by the liquidity provided by the buyer, facilitating the creation of 'phantom' funds. This flaw compromises the integrity of the token supply and allows for the extraction of value that did not previously exist in the market escrow, effectively functioning as a protocol-level minting vulnerability.\nThe issue is fixed in version 1.7.19 by ensuring that settlement calculations utilize synchronized data references or implement strictly enforced bounds checks to prevent total fee distributions from exceeding the transaction's bid value."
}