CVE-2026-82406

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.

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.

Location: core/kapp/market/market.go — Buy() (approx. L281–436)
Severity: High

The native marketplace enforces an IsClaimed guard in Claim (market.go:752), CancelOrder (market.go:1125), and orderEscrowAmount (market.go:251), but not in Buy.

Marketplace escrow is virtual: the market KApp account never custodies currency. A bid burns funds from the bidder (bidderAcc.SubFromBalance, ~L378), and refunds/payouts mint to the recipient (AddToBalance, e.g. the prior-bidder refund at ~L349). Soundness depends on each order's CurrentBid being paid out exactly once.

A seller can settle a resting-bid auction early via the seller-accept branch of Claim (~L776) → executeBuyMarket (~L656). That path sets IsClaimed=true, delivers the NFT, pays the seller, and re-saves the order (SetMarketOrder, ~L726) — but, unlike every other settle path, it does not reset EndTime (contrast immediate-buy Buy ~L416 and CancelOrder ~L1206), and no code path deletes the order. The result is a "zombie" order: already settled, yet still loadable with EndTime in the future and a stale CurrentBidder.

Because Buy has no IsClaimed guard, a new bidder can still Buy on that settled order (the bid guard at ~L317 only forces the new amount Y > CurrentBid X). The new bidder is debited Y; the prior bidder is refunded X (funded by the new bidder, not minted); the new bidder becomes CurrentBidder on an IsClaimed order and can then neither Claim (reverts on IsClaimed) nor CancelOrder (reverts on IsClaimed). Their funds are lost permanently.

Attack sequence (permissionless , anyone can create a sell order):

1. Attacker (seller S) creates a resting-bid auction (Price=0, ReservePrice>0) for an NFT and self-bids X as bidder A (Sybil).
2. S accepts A's bid early via Claim → NFT goes to A (= attacker, keeps it), S (= attacker) collects the owner payout, order marked IsClaimed=true but left "live".
3. Victim B bids Y > X on the still-live-looking auction via Buy. Buy refunds prior bidder A the amount X (AddToBalance, L349) and burns Y from B (SubFromBalance, L378).
4. B is now CurrentBidder on a claimed order and can neither Claim nor CancelOrder — both revert on IsClaimed. B's Y is unrecoverable; X of it was siphoned to A; Y−X is destroyed.

POC

package market

import (
	"testing"

	"github.com/klever-io/klever-go/common/mock"
	"github.com/klever-io/klever-go/core/kapp"
	"github.com/klever-io/klever-go/core/process/kda/kdautils"
	"github.com/klever-io/klever-go/data/block"
	"github.com/klever-io/klever-go/data/state"
	"github.com/klever-io/klever-go/data/transaction"
	"github.com/klever-io/klever-go/kapps"
	"github.com/klever-io/klever-go/kvm/mock/stub"
	"github.com/stretchr/testify/require"
)

// TestPoC_ZombieOrder_MissingIsClaimedGuardInBuy proves the fund-loss / theft
// vulnerability caused by `Buy` lacking the `IsClaimed` guard that `Claim`
// (market.go L752) and `CancelOrder` (market.go L1125) both enforce.
//
// Attack (attacker A == seller S, victim B):
//  1. S lists an NFT as an Auction with Price=0, ReservePrice=R (bids REST).
//  2. A places a resting bid X >= R via Buy (records CurrentBid/CurrentBidder,
//     no settlement because Price==0).
//  3. S accepts the resting bid early via Claim's seller-accept branch (L776),
//     which routes to executeBuyMarket: IsClaimed=true, NFT delivered to A,
//     proceeds paid to S(=A). This settle path is the ONLY one that does NOT
//     reset EndTime and does NOT delete the order -> the order becomes a live
//     "zombie" (IsClaimed=true, EndTime in the future, still loadable).
//  4. Victim B calls Buy on the zombie order with Y > X. Buy has no IsClaimed
//     guard, so it SUCCEEDS: B is debited Y, prior bidder A is "refunded" X
//     (funded by B), and B becomes CurrentBidder on an already-claimed order.
//  5. B can NEITHER Claim…

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.

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.

Location: core/kapp/market/market.go — Buy() (approx. L281–436)
Severity: High

The native marketplace enforces an IsClaimed guard in Claim (market.go:752), CancelOrder (market.go:1125), and orderEscrowAmount (market.go:251), but not in Buy.

Marketplace escrow is virtual: the market KApp account never custodies currency. A bid burns funds from the bidder (bidderAcc.SubFromBalance, ~L378), and refunds/payouts mint to the recipient (AddToBalance, e.g. the prior-bidder refund at ~L349). Soundness depends on each order's CurrentBid being paid out exactly once.

A seller can settle a resting-bid auction early via the seller-accept branch of Claim (~L776) → executeBuyMarket (~L656). That path sets IsClaimed=true, delivers the NFT, pays the seller, and re-saves the order (SetMarketOrder, ~L726) — but, unlike every other settle path, it does not reset EndTime (contrast immediate-buy Buy ~L416 and CancelOrder ~L1206), and no code path deletes the order. The result is a "zombie" order: already settled, yet still loadable with EndTime in the future and a stale CurrentBidder.

Because Buy has no IsClaimed guard, a new bidder can still Buy on that settled order (the bid guard at ~L317 only forces the new amount Y > CurrentBid X). The new bidder is debited Y; the prior bidder is refunded X (funded by the new bidder, not minted); the new bidder becomes CurrentBidder on an IsClaimed order and can then neither Claim (reverts on IsClaimed) nor CancelOrder (reverts on IsClaimed). Their funds are lost permanently.

Attack sequence (permissionless , anyone can create a sell order):

1. Attacker (seller S) creates a resting-bid auction (Price=0, ReservePrice>0) for an NFT and self-bids X as bidder A (Sybil).
2. S accepts A's bid early via Claim → NFT goes to A (= attacker, keeps it), S (= attacker) collects the owner payout, order marked IsClaimed=true but left "live".
3. Victim B bids Y > X on the still-live-looking auction via Buy. Buy refunds prior bidder A the amount X (AddToBalance, L349) and burns Y from B (SubFromBalance, L378).
4. B is now CurrentBidder on a claimed order and can neither Claim nor CancelOrder — both revert on IsClaimed. B's Y is unrecoverable; X of it was siphoned to A; Y−X is destroyed.

POC

package market

import (
	"testing"

	"github.com/klever-io/klever-go/common/mock"
	"github.com/klever-io/klever-go/core/kapp"
	"github.com/klever-io/klever-go/core/process/kda/kdautils"
	"github.com/klever-io/klever-go/data/block"
	"github.com/klever-io/klever-go/data/state"
	"github.com/klever-io/klever-go/data/transaction"
	"github.com/klever-io/klever-go/kapps"
	"github.com/klever-io/klever-go/kvm/mock/stub"
	"github.com/stretchr/testify/require"
)

// TestPoC_ZombieOrder_MissingIsClaimedGuardInBuy proves the fund-loss / theft
// vulnerability caused by `Buy` lacking the `IsClaimed` guard that `Claim`
// (market.go L752) and `CancelOrder` (market.go L1125) both enforce.
//
// Attack (attacker A == seller S, victim B):
//  1. S lists an NFT as an Auction with Price=0, ReservePrice=R (bids REST).
//  2. A places a resting bid X >= R via Buy (records CurrentBid/CurrentBidder,
//     no settlement because Price==0).
//  3. S accepts the resting bid early via Claim's seller-accept branch (L776),
//     which routes to executeBuyMarket: IsClaimed=true, NFT delivered to A,
//     proceeds paid to S(=A). This settle path is the ONLY one that does NOT
//     reset EndTime and does NOT delete the order -> the order becomes a live
//     "zombie" (IsClaimed=true, EndTime in the future, still loadable).
//  4. Victim B calls Buy on the zombie order with Y > X. Buy has no IsClaimed
//     guard, so it SUCCEEDS: B is debited Y, prior bidder A is "refunded" X
//     (funded by B), and B becomes CurrentBidder on an already-claimed order.
//  5. B can NEITHER Claim…

Klever-Go: Zombie-order theft: Buy missing IsClaimed guard in native marketplace in github.com/klever-io/klever-go