CVE-2026-82406 in Klever-Go
Summary
by MITRE • 09/23/2026
Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.20, the native marketplace function core/kapp/market/market.go Buy does not check IsClaimed before accepting a bid. A seller can use the Claim seller-accept branch to settle a resting-bid auction while 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. Because Claim and CancelOrder reject the later bidder when IsClaimed is true, the later bidder cannot obtain the NFT or recover the funds. This issue is fixed in version 1.7.20.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The Klever-Go blockchain protocol implementation contains a critical logic flaw within its native marketplace functionality that compromises the integrity of auction-based transactions involving non-fungible tokens. Specifically, the Buy function located in the core/kapp/market/market.go module fails to verify the IsClaimed status before accepting new bids or processing settlements. This oversight creates a state inconsistency where a seller can utilize the Claim operation on the seller-accept branch to finalize a resting-bid auction while leaving the associated order record in an invalid state. In this compromised state, the order remains loadable with outdated metadata, including stale values for CurrentBid and CurrentBidder, despite the asset having already been transferred or claimed by the initial recipient.
The operational impact of this vulnerability allows for a double-spend-like scenario that results in significant financial loss for subsequent participants without providing them recourse. When a later bidder submits a higher bid under these conditions, they are debited their funds as part of the transaction process. However, because the underlying order state is corrupted by the previous claim operation, the system incorrectly triggers a refund to the earlier bidder who already received the NFT. This creates an arbitrage opportunity where assets can be effectively duplicated or transferred without proper payment settlement from all parties involved in the chain of transactions.
The severity of this issue is compounded by the fact that standard recovery mechanisms are rendered ineffective due to the same underlying logic error. When a later bidder attempts to resolve their loss, they encounter rejection when trying to use either the Claim or CancelOrder functions because these operations check for IsClaimed status and reject requests if it is true. Consequently, the later bidder is left in an unrecoverable position where they have lost funds but cannot obtain the NFT nor retrieve their payment through standard protocol channels. This represents a fundamental failure in state management that undermines trust in the marketplace's ability to enforce atomicity of asset transfer and fund settlement.
This vulnerability aligns with CWE-841, which describes Improper Enforcement of Behavioral Validity, as the application fails to maintain consistent rules for valid states during transaction processing. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, insofar as the race condition between claiming and bidding leads to inconsistent state updates that are not properly serialized or validated against current asset ownership status. From a threat modeling perspective, this flaw can be categorized under MITRE ATT&CK technique T1498, Network Denial of Service, specifically regarding resource exhaustion through financial loss for legitimate users, although it is more accurately described as an integrity violation within the application layer logic rather than a traditional denial-of-service attack.
To mitigate such vulnerabilities in blockchain smart contracts and marketplace implementations, developers must enforce strict state machine transitions that validate all preconditions before executing asset transfers or fund movements. The IsClaimed flag should be checked at every stage of the auction lifecycle to ensure that no further bids are accepted once an item has been claimed by a previous party. Additionally, implementing atomic transactions where both the transfer of ownership and the settlement of funds occur simultaneously can prevent scenarios where one part succeeds while the other fails or leaves residual state inconsistencies. Regular auditing of market logic against edge cases involving stale data and concurrent access patterns is essential to maintain the integrity of decentralized marketplace operations.