{"id":"CVE-2026-54754","aliases":["EUVD-2026-67824","GHSA-p7gw-2pcp-5pf8","GO-2026-6315","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Klever-Go: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped)","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.","severity":{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00432,"percentile":0.37814,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-191","CWE-367","CWE-682"],"published":"2026-08-28T16:20:06Z","modified":"2026-10-28T02:31:14Z","fixes":[{"ecosystem":"Go","package":"github.com/klever-io/klever-go","fixed_in":["1.7.19"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/klever-io/klever-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.7.19"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/klever-io/klever-go","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.7.19"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/klever-io/klever-go","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.7.19"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39}],"products":[{"vendor":"klever-io","product":"klever-go"}],"references":[{"url":"https://github.com/klever-io/klever-go/security/advisories/GHSA-p7gw-2pcp-5pf8","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/klever-io/klever-go/releases/tag/v1.7.19","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-p7gw-2pcp-5pf8"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/54xxx/CVE-2026-54754.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-54754","tags":["advisory"]},{"url":"https://github.com/klever-io/klever-go","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623692-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-20909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-22547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24690","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25718","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26232","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26247","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26307","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27878","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28705","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54746","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54754","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54755","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55066","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55108","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55761","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55784","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55785","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56854","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78662","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623712-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-54754","title":"Klever-Go: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped)","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.","status":"published","published":"2026-08-28T16:20:06.585Z","modified":"2026-08-31T18:52:12.908Z","cvss":[{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-191","CWE-367","CWE-682"],"updated_at":"2026-11-02T13:38:09.774038Z"}],"euvd":[{"id":"EUVD-2026-67824","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.","status":"published","published":"2026-08-28T16:20:06Z","modified":"2026-08-31T18:52:12Z","cvss":[{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T18:01:20.215322Z"}],"ghsa":[{"id":"GHSA-p7gw-2pcp-5pf8","title":"Klever: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped)","description":"## Summary\n\nWhen a marketplace order is settled (`MarketBuy` / `BuyItNow`, and auction `Claim`), the buyer's\npayment is split three ways — **referral**, **royalties**, and the **seller (market-order owner)\nremainder**:\n\n```\nmarketOwnerAmount = CurrentBid − referralAmount − royaltiesAmount\n```\n\nReferral and royalties are paid out **unconditionally**, but the seller remainder is only paid\n**when positive** (`computeMarketOwnerAmount` returns `Ok` and pays nothing when the amount is\n`\u003c= 0`). When `referral% + royalty%` exceeds 100% of the bid, `marketOwnerAmount` goes **negative**\nand is silently skipped — so the marketplace pays out **more KLV / sale currency than the buyer\npaid in**, minting the difference out of thin air.\n\nThe combined ceiling `royalty% + referral% \u003c= 100%` **is** checked once, at listing time (`Sell`).\nBut the two percentages are sourced asymmetrically at settlement:\n\n- **referral %** is **snapshotted** into the order at `Sell` (`MarketOrderData.ReferralPercentage`);\n- **royalty %** is **never snapshotted** — it is read **live** from the asset at buy time\n  (`asset.Royalties.MarketPercentage`).\n\nSo the listing-time invariant is a **time-of-check/time-of-use** guarantee only. After a valid\nlisting, the asset owner raises the royalty `MarketPercentage` via `AssetTrigger → UpdateRoyalties`;\nat the next buy the live royalty plus the snapshotted referral exceed 100%, and the settlement mints\nthe overflow. The minted funds land in attacker-controlled referral / royalty addresses.\n\nThis was **actively exploited on mainnet** (see *Evidence*), minting tens of millions of KLV before\nthe emergency guard was deployed.\n\n## Affected component\n\n- Repository: `klever-io/klever-go` (node).\n- Settlement / mint site: `core/kapp/market/market.go` — `executeBuyMarket` (L575+),\n  `computeReferralAmount` (L361+), `computeRoyaltiesAmount` (L490+),\n  `computeRoyaltiesFixedDeposit` (L443+), `computeMarketOwnerAmount` (L540+).\n- TOCTOU sources: `Sell` combined check (`market.go:908`), order snapshot of referral but **not**\n  royalty (`market.go:997`), live royalty mutation via\n  `core/kapp/kda/trigger.go` — `handleUpdateRoyaltiesNFTandSFT` (L613+, sets\n  `asset.Royalties.MarketPercentage` at L670).\n- Reachable from both `Buy` (BuyItNow, `market.go:204+`) and auction `Claim`\n  (`market.go:705`, `market.go:731`).\n- Pre-fix: **not** gated by any fork flag — exploitable on mainnet. The fix is gated behind the new\n  `FixMarketBuyOverflow` activation-epoch flag.\n\n---\n\n## Root cause\n\n### 1. Settlement pays referral + royalty unconditionally, seller remainder only if positive\n`core/kapp/market/market.go` — `executeBuyMarket` (L575+):\n```go\nreferralAmount, _  := tools.ComputePercentageI64(marketOrder.CurrentBid,\n                          int64(marketOrder.ReferralPercentage), ...)        // L583: SNAPSHOT referral %\nroyaltiesAmount, _ := tools.ComputePercentageI64(marketOrder.CurrentBid,\n                          int64(asset.Royalties.MarketPercentage), ...)      // L587: LIVE royalty %\nmarketOwnerAmount := marketOrder.CurrentBid - referralAmount - royaltiesAmount  // L591: can go negative\n\n// ---- FIX (FixMarketBuyOverflow), added by the patch ----\nif m.forkController.FixMarketBuyOverflow() \u0026\u0026 marketOwnerAmount \u003c 0 {         // L593-596\n    ctx.Receipts().AddError(ctx.ContractID(), common.ErrFieldInvalidRoyalties, common.ErrInvalidValue.Error())\n    return transaction.Transaction_AmountInvalid, common.ErrInvalidValue\n}\n\nm.computeReferralAmount(ctx, marketOrder, referralAmount, currencyID)   // pays referral in full\nm.computeRoyaltiesFixedDeposit(ctx, marketOrder, asset)                 // pays fixed royalty (KLV)\nm.computeRoyaltiesAmount(ctx, marketOrder, asset, currencyID, royaltiesAmount) // pays % royalty in full\nm.computeMarketOwnerAmount(ctx, marketOrder, currencyID, marketOwnerAmount)    // \u003c-- skips when \u003c= 0\n```\n`computeMarketOwnerAmount` (L540-542) — the silent skip:\n```go\nfunc (m *marketKapp) computeMarketOwnerAmount(... marketOwnerAmount int64) (... , error) {\n\tif marketOwnerAmount \u003c= 0 {\n\t\treturn transaction.Transaction_Ok, nil   // negative seller share dropped, NO error\n\t}\n\t// ... AddToBalance(marketOwnerAmount) ...\n}\n```\nMeanwhile `computeReferralAmount` (L376) and `computeRoyaltiesAmount` (L515) each `AddToBalance(...)`\nthe full computed amount with **no matching debit** from the buyer beyond the single\n`bidderAcc.SubFromBalance(amount)` taken in `Buy` (`market.go:301`).\n\n**Conservation breaks:** buyer is debited `bid` once; recipients are credited\n`referralAmount + royaltiesAmount`. When that sum `\u003e bid`, the surplus\n`(referralAmount + royaltiesAmount − bid)` is **minted**.\n\n### 2. The combined ≤100% invariant is enforced only at listing time\n`Sell` (`market.go:908`) correctly rejects a listing whose combined cut exceeds 100%:\n```go\nif asset.Royalties.MarketPercentage + marketplace.ReferralPercentage \u003e core.HundredPercent {\n\treturn transaction.Transaction_ParameterInvalid, common.ErrInvalidValue\n}\n```\n…and snapshots **referral** into the order, but **not** royalty (`market.go:997-998`):\n```go\nmarketOrder := \u0026kapps.MarketOrderData{\n\t// ...\n\tReferralPercentage:    marketplace.ReferralPercentage, // snapshotted\n\tRoyaltiesFixedDeposit: asset.Royalties.MarketFixed,    // snapshotted\n\t// NOTE: asset.Royalties.MarketPercentage is NOT snapshotted -\u003e read live at buy\n}\n```\n`MarketOrderData` has no field for the royalty percentage (`kapps/market.pb.go`), so settlement\nalways re-reads it live from the (mutable) asset.\n\n### 3. Royalty % is mutable after listing\n`core/kapp/kda/trigger.go` — `handleUpdateRoyaltiesNFTandSFT` (L613+) lets the asset owner overwrite\n`asset.Royalties.MarketPercentage` (L670) with only a **per-field** `\u003c= 100%` check (`CheckValid100Params`,\nL651) — it has no knowledge of any outstanding marketplace listing's snapshotted referral. So the\nowner can list at, e.g., referral 100% / royalty 0% (sum 100%, passes `Sell`), then raise royalty to\n100%, making the buy-time sum 200%.\n\n\u003e The shipped emergency-guard source documents this exact vector:\n\u003e *\"The royalty percentage is read live at buy time, so a listing made now can be weaponised later\n\u003e via UpdateRoyalties.\"* (`common/emergencyGuard.go`)\n\n**Net effect:** `referralAmount + royaltiesAmount = bid + bid = 2·bid`; `marketOwnerAmount = −bid`\n(skipped); **`bid` KLV minted per settlement**, paid to attacker-controlled addresses.\n\n---\n\n## Proof of Concept\n\n### A. Committed regression test (deterministic, runnable today)\n`core/kapp/market/market_test.go` — `TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation`.\nIt builds an order with `ReferralPercentage = 100%` and an asset with `MarketPercentage = 100%`\n(the attacker is both the referral and the royalty address), then settles a `bid` of\n`25,600,000 KLV` (`25600000000000` base units):\n\n```bash\ngo test ./core/kapp/market/ -run TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation -v\n```\n\n- `FixDisabled_MintsKLVFromThinAir`: settlement returns `Ok`; the attacker address ends with\n  `2·bid` credited while only `bid` was paid in — i.e. **`bid` KLV minted**.\n- `FixEnabled_RejectsInflation`: with `FixMarketBuyOverflow` on, settlement returns\n  `Transaction_AmountInvalid` and the attacker balance stays `0` — **no payout runs**.\n\n### B. End-to-end on a local node (the real attack path)\nA single-node local network is sufficient. The exploit is four transactions from one ordinary\nfunded account; nothing privileged is required.\n\n1. **Create an NFT collection** you own, with `royalties.marketPercentage = 0` and a royalties\n   address you control.\n2. **Create a marketplace** with `referralPercentage = 10000` (100%) and a referral address you\n   control (`CreateMarketplace`).\n3. **List** one NFT for sale (`Sell`) on that marketplace. The `Sell` check passes because\n   `0 (royalty) + 10000 (referral) = 10000 = HundredPercent`. The order snapshots\n   `ReferralPercentage = 10000`.\n4. **Raise the royalty** on the asset to 100% (`AssetTrigger / UpdateRoyalties`,\n   `marketPercentage = 10000`). Allowed: the per-field check passes and the live combined invariant\n   is never re-evaluated against the open listing.\n5. **Buy** the listing (`MarketBuy`) from a second account (or settle the auction via `Claim`).\n   `referralAmount = bid`, `royaltiesAmount = bid`, `marketOwnerAmount = −bid` (skipped). Your\n   referral + royalty addresses receive `2·bid`; the buyer paid `bid`; **`bid` KLV is minted**.\n\nBecause the attacker controls buyer, seller, referral and royalty addresses, the only real cost is\ntransaction fees; the cycle is repeatable until supply targets are met.\n\n---\n\n## Evidence\n\n### Regression test (local, verbatim)\n```\n=== RUN   TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation\n=== RUN   TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixDisabled_MintsKLVFromThinAir\n=== RUN   TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixEnabled_RejectsInflation\n--- PASS: TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation (0.00s)\n    --- PASS: TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixDisabled_MintsKLVFromThinAir (0.00s)\n    --- PASS: TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixEnabled_RejectsInflation (0.00s)\nPASS\nok  \tgithub.com/klever-io/klever-go/core/kapp/market\t0.279s\n```\n`FixDisabled` asserts the attacker balance equals `2·bid = 51,200,000 KLV` for a single settlement\n(`bid = 25,600,000 KLV`), with `bid` of that minted. `FixEnabled` asserts rejection and a `0`\nbalance.\n\n### Mainnet exploitation (observed)\nThe bug was exploited in production, and was **detected and characterised externally** by the\ncommunity monitoring project **[KleverPuls / kpulse.tech](https://kpulse.tech)** before the root\ncause was known internally. Over a ~24h window kpulse isolated a single wallet (opened\n**2026-06-04**, ~**204 transactions** in ~24h, funded only by a ~**242K KLV KuCoin withdrawal**, no\ntreasury/foundation funding) that:\n\n- **self-issued 3 NFT collections named \"InflationPOC\"** and **wash-traded one (`NFLATION-ESGO/1`)\n  29 times** through self-created marketplaces — ~**$450K of artificial, economically empty NFT\n  volume**;\n- **swapped the proceeds KLV → USDC / USDT / WBTC / WETH on KleverSwap** and **bridged ~$72K of value\n  to Ethereum** via wrapped-asset burns over 24h (USDC −12,487 ≈ $12.5K; USDT −26,362 ≈ $26.4K; WBTC\n  −0.31 ≈ $19.6K; WETH −7.55 ≈ $14K);\n- surfaced a spurious **\"1.86B KLV outflow\"** headline that kpulse correctly identified as a\n  wash-trade **receipt-doubling** artifact with small real net KLV flow.\n\nThat \"doubling of marketplace receipts\" is **precisely the on-chain signature of this bug**: each\nabusive settlement pays out a referral cut (`bid`) **plus** a royalty cut (`bid`) while the buyer paid\nonly `bid` once — the market contract emits ~2× the value it took in, which *is* the mint. The\nattacker's self-issued collection and self-created marketplaces are exactly the self-dealing setup the\nregression test reproduces (the test reuses the real on-chain identifiers: `collectionID =\n\"NFLATION-ESGO\"`, asset `1`, market name \"Inflation Market\").\n\nkpulse could not determine the cause from on-chain data alone and flagged the activity for\nconfirmation; the Klever core team then traced it to the referral+royalty settlement defect described\nabove and shipped the emergency guard + protocol fix.\n\nEach abusive settlement minted one `bid` of KLV; the observed `bid` was `25,600,000 KLV`, repeated and\nfunnelled through a short hop chain before being swapped and bridged. The emergency guard\n(`common/emergencyGuard.go`) blocks the following observed sender public keys (hex):\n\n| Public key (hex) | Address | Role (observed) |\n|---|---|---|\n| `54ea28e527d4136508be955374afa54a8c25c19a48c674f412f7ce02db0f4e1b` | `klv12n4z3ef86sfk2z97j4fhfta9f2xztsv6frr8faqj7l8q9kc0fcdsfjfqez` | root / minter |\n| `bb687dbba23e1844fec674a32cb8809f0d3207506c53fc3d637e40dc56708d63` | `klv1hd58mwaz8cvyflkxwj3jewyqnuxnyp6sd3flc0tr0eqdc4ns343skngdjq` | collector hop (~125M KLV) |\n| `77388d3dfe6cd88e8da723254c11abf3d9cccb6fb77b000e5038fc3ff92b964d` | `klv1wuug6007dnvgard8yvj5cydt70vuejm0kaasqrjs8r7rl7ftjexsglalf6` | direct recipient (25.6M, idle) |\n| `a196789b026f996867f08317cc6c5a4eb9ad3a59b1be3716420bc8692d4c3048` | `klv15xt83xczd7vkselssvtucmz6f6u66wjekxlrw9jzp0yxjt2vxpyq2nawrw` | hop-2 recipient (25M) |\n\nThe single-`bid` per-settlement size (25.6M KLV) matches the \"direct recipient, 25.6M\" entry, and the\n~125M at the collector hop is consistent with roughly five abusive settlements.\n\n---\n\n## Impact\n\n- **Unbounded inflation of KLV** (and of any sale currency used for the listing), repeatable for only\n  transaction fees, by any account that creates its own collection + marketplace.\n- The minted KLV is created by direct `AddToBalance` to attacker addresses (no tracked `Mint`), so\n  the asset's booked supply does not change — the inflation is **off the books** and only detectable\n  by summing balances / auditing receipts (it surfaces on-chain as *doubled* marketplace receipts).\n- **Realized impact (observed):** the attacker minted KLV via ~29 self-dealt settlements, swapped to\n  stable/wrapped assets on KleverSwap, and **off-ramped ~$72K to Ethereum via the bridge** (USDC,\n  USDT, WBTC, WETH) before the emergency guard halted the activity, alongside ~$450K of artificial\n  NFT wash-trade volume.\n- Total loss of economic integrity for all KLV / token holders.\n\n## Who can exploit it / prerequisites\n\n- **Any account** that can pay the one-time collection-create + marketplace-create fees and tx\n  fees. No roles, admin, or allowlist.\n- **Any client.** The settlement is triggered by standard `MarketBuy` / `Claim` contracts POSTed to\n  the public, unauthenticated `/transaction/send` RPC (`network/api/transaction/routes.go`,\n  `SendTX` / `BroadcastTX`). The `operator` CLI, the SDKs, or a hand-signed `curl` all work.\n- Deterministic; the abusive state is reached with one extra `UpdateRoyalties` after a normal listing.\n\n---\n\n## Remediation\n\nShipped as a layered response (embargoed):\n\n### Layer 0 — emergency guard (deployed first, fork-proof) — `GHSA-p7gw` rc1\n`common/emergencyGuard.go` + `data/transaction/emergencyGuard.go`: matching transactions are kept\nout of blocks this node proposes (`core/process/block/preprocess/transactions.go`) and refused at\nthe node API (`node.go` `SendTransaction` / `SendBulkTransactions`). It **never changes block\nvalidity**, so a partial-fleet rollout cannot fork the chain. It blocks the known attacker senders\n(all contract types) plus all `MarketBuy`, `Sell`, and `CreateMarketplace` / `ConfigMarketplace`\noperations while the protocol fix rolls out. Enforcement is by proposer cooperation, not protocol —\ncoverage equals the share of block producers running the guard.\n\n### Layer 1 — protocol fix (consensus, epoch-gated) — `GHSA-p7gw` rc2\n`core/kapp/market/market.go:593` rejects the settlement when `marketOwnerAmount \u003c 0`, **before any\npayout runs**, returning `Transaction_AmountInvalid`. Gated behind the new `FixMarketBuyOverflow`\nactivation-epoch flag (`config/enableEpochs.*`, `core/fork/forks.go`, `core/interface.go`) so\nhistorical blocks reprocess identically. Covered by\n`TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation`.\n\n### Recommended hardening (defense in depth)\n1. **Snapshot the royalty %** into `MarketOrderData` at `Sell` (as referral already is) and pay from\n   the snapshot, eliminating the TOCTOU entirely; or re-evaluate the combined\n   `referral% + royalty% \u003c= 100%` invariant at settlement.\n2. Treat a **negative** seller remainder as a hard error everywhere, and only treat exactly `0` as a\n   no-op skip (`computeMarketOwnerAmount`), so a future regression aborts the tx instead of minting.\n3. After splitting a payment pool, **assert conservation** (`referral + royalties + ownerShare == bid`)\n   so any drift aborts the transaction.\n\n---\n\n## Notes\n\n- Triggered by both BuyItNow (`Buy`) and auction settlement (`Claim`).\n- The same family of \"pay full cut, silently drop the negative remainder\" minting also exists in the\n  royalty-split paths and is tracked separately under **GHSA-cgc5-v3f2-8m2v** (split-royalty `uint32`\n  overflow). This advisory covers the top-level referral+royalty \u003e bid case; the\n  `FixMarketBuyOverflow` guard here only checks `marketOwnerAmount`, not intra-split over-payments.\n\n## Acknowledgments\n\n- **[KleverPuls / kpulse.tech](https://kpulse.tech)** — community monitoring project that **first\n  detected and characterised the exploitation in the wild**. kpulse isolated the attacker wallet and\n  its \"InflationPOC\" collections, identified the marketplace wash-trading of `NFLATION-ESGO/1` and the\n  KleverSwap → bridge off-ramp (~$72K to Ethereum), and flagged the anomalous *doubling* of\n  marketplace receipts — the exact on-chain signature of this bug — prompting the incident response\n  that led to this fix. The root cause was then identified and remediated by the Klever core team.\n\n## Source\n\n- Vulnerable / fixed code: `core/kapp/market/market.go:540-545,575-596,908,997-998`,\n  `core/kapp/kda/trigger.go:613-676`, `core/process/kda/assetHelper.go:101`,\n  `tools/converters.go:102`, `core/constants.go:18`.\n- Emergency guard: `common/emergencyGuard.go`, `data/transaction/emergencyGuard.go`,\n  `core/process/block/preprocess/transactions.go`, `node/node.go`.\n- Fork flag: `config/enableEpochs.go`, `config/node/enableEpochs.yaml`, `core/fork/forks.go`,\n  `core/interface.go`.\n- Regression test: `core/kapp/market/market_test.go`\n  (`TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation`).","status":"published","published":"2026-08-28T16:22:15Z","modified":"2026-08-28T16:22:16Z","cvss":[{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical"}],"cwes":["CWE-191","CWE-367","CWE-682"],"updated_at":"2026-11-02T14:41:07.031507Z"}],"nvd":[{"id":"CVE-2026-54754","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.","status":"published","published":"2026-08-28T20:18:17.533Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-191","CWE-367","CWE-682"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-54754","title":"Klever-Go: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped)","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.","status":"published","published":"2026-08-28T16:20:06.585Z","modified":"2026-10-28T02:31:14.359705443Z","cvss":[{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical"}],"cwes":["CWE-191","CWE-367","CWE-682"],"updated_at":"2026-11-02T15:45:10.818486Z"},{"id":"GHSA-p7gw-2pcp-5pf8","title":"Klever: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped)","description":"## Summary\n\nWhen a marketplace order is settled (`MarketBuy` / `BuyItNow`, and auction `Claim`), the buyer's\npayment is split three ways — **referral**, **royalties**, and the **seller (market-order owner)\nremainder**:\n\n```\nmarketOwnerAmount = CurrentBid − referralAmount − royaltiesAmount\n```\n\nReferral and royalties are paid out **unconditionally**, but the seller remainder is only paid\n**when positive** (`computeMarketOwnerAmount` returns `Ok` and pays nothing when the amount is\n`\u003c= 0`). When `referral% + royalty%` exceeds 100% of the bid, `marketOwnerAmount` goes **negative**\nand is silently skipped — so the marketplace pays out **more KLV / sale currency than the buyer\npaid in**, minting the difference out of thin air.\n\nThe combined ceiling `royalty% + referral% \u003c= 100%` **is** checked once, at listing time (`Sell`).\nBut the two percentages are sourced asymmetrically at settlement:\n\n- **referral %** is **snapshotted** into the order at `Sell` (`MarketOrderData.ReferralPercentage`);\n- **royalty %** is **never snapshotted** — it is read **live** from the asset at buy time\n  (`asset.Royalties.MarketPercentage`).\n\nSo the listing-time invariant is a **time-of-check/time-of-use** guarantee only. After a valid\nlisting, the asset owner raises the royalty `MarketPercentage` via `AssetTrigger → UpdateRoyalties`;\nat the next buy the live royalty plus the snapshotted referral exceed 100%, and the settlement mints\nthe overflow. The minted funds land in attacker-controlled referral / royalty addresses.\n\nThis was **actively exploited on mainnet** (see *Evidence*), minting tens of millions of KLV before\nthe emergency guard was deployed.\n\n## Affected component\n\n- Repository: `klever-io/klever-go` (node).\n- Settlement / mint site: `core/kapp/market/market.go` — `executeBuyMarket` (L575+),\n  `computeReferralAmount` (L361+), `computeRoyaltiesAmount` (L490+),\n  `computeRoyaltiesFixedDeposit` (L443+), `computeMarketOwnerAmount` (L540+).\n- TOCTOU sources: `Sell` combined check (`market.go:908`), order snapshot of referral but **not**\n  royalty (`market.go:997`), live royalty mutation via\n  `core/kapp/kda/trigger.go` — `handleUpdateRoyaltiesNFTandSFT` (L613+, sets\n  `asset.Royalties.MarketPercentage` at L670).\n- Reachable from both `Buy` (BuyItNow, `market.go:204+`) and auction `Claim`\n  (`market.go:705`, `market.go:731`).\n- Pre-fix: **not** gated by any fork flag — exploitable on mainnet. The fix is gated behind the new\n  `FixMarketBuyOverflow` activation-epoch flag.\n\n---\n\n## Root cause\n\n### 1. Settlement pays referral + royalty unconditionally, seller remainder only if positive\n`core/kapp/market/market.go` — `executeBuyMarket` (L575+):\n```go\nreferralAmount, _  := tools.ComputePercentageI64(marketOrder.CurrentBid,\n                          int64(marketOrder.ReferralPercentage), ...)        // L583: SNAPSHOT referral %\nroyaltiesAmount, _ := tools.ComputePercentageI64(marketOrder.CurrentBid,\n                          int64(asset.Royalties.MarketPercentage), ...)      // L587: LIVE royalty %\nmarketOwnerAmount := marketOrder.CurrentBid - referralAmount - royaltiesAmount  // L591: can go negative\n\n// ---- FIX (FixMarketBuyOverflow), added by the patch ----\nif m.forkController.FixMarketBuyOverflow() \u0026\u0026 marketOwnerAmount \u003c 0 {         // L593-596\n    ctx.Receipts().AddError(ctx.ContractID(), common.ErrFieldInvalidRoyalties, common.ErrInvalidValue.Error())\n    return transaction.Transaction_AmountInvalid, common.ErrInvalidValue\n}\n\nm.computeReferralAmount(ctx, marketOrder, referralAmount, currencyID)   // pays referral in full\nm.computeRoyaltiesFixedDeposit(ctx, marketOrder, asset)                 // pays fixed royalty (KLV)\nm.computeRoyaltiesAmount(ctx, marketOrder, asset, currencyID, royaltiesAmount) // pays % royalty in full\nm.computeMarketOwnerAmount(ctx, marketOrder, currencyID, marketOwnerAmount)    // \u003c-- skips when \u003c= 0\n```\n`computeMarketOwnerAmount` (L540-542) — the silent skip:\n```go\nfunc (m *marketKapp) computeMarketOwnerAmount(... marketOwnerAmount int64) (... , error) {\n\tif marketOwnerAmount \u003c= 0 {\n\t\treturn transaction.Transaction_Ok, nil   // negative seller share dropped, NO error\n\t}\n\t// ... AddToBalance(marketOwnerAmount) ...\n}\n```\nMeanwhile `computeReferralAmount` (L376) and `computeRoyaltiesAmount` (L515) each `AddToBalance(...)`\nthe full computed amount with **no matching debit** from the buyer beyond the single\n`bidderAcc.SubFromBalance(amount)` taken in `Buy` (`market.go:301`).\n\n**Conservation breaks:** buyer is debited `bid` once; recipients are credited\n`referralAmount + royaltiesAmount`. When that sum `\u003e bid`, the surplus\n`(referralAmount + royaltiesAmount − bid)` is **minted**.\n\n### 2. The combined ≤100% invariant is enforced only at listing time\n`Sell` (`market.go:908`) correctly rejects a listing whose combined cut exceeds 100%:\n```go\nif asset.Royalties.MarketPercentage + marketplace.ReferralPercentage \u003e core.HundredPercent {\n\treturn transaction.Transaction_ParameterInvalid, common.ErrInvalidValue\n}\n```\n…and snapshots **referral** into the order, but **not** royalty (`market.go:997-998`):\n```go\nmarketOrder := \u0026kapps.MarketOrderData{\n\t// ...\n\tReferralPercentage:    marketplace.ReferralPercentage, // snapshotted\n\tRoyaltiesFixedDeposit: asset.Royalties.MarketFixed,    // snapshotted\n\t// NOTE: asset.Royalties.MarketPercentage is NOT snapshotted -\u003e read live at buy\n}\n```\n`MarketOrderData` has no field for the royalty percentage (`kapps/market.pb.go`), so settlement\nalways re-reads it live from the (mutable) asset.\n\n### 3. Royalty % is mutable after listing\n`core/kapp/kda/trigger.go` — `handleUpdateRoyaltiesNFTandSFT` (L613+) lets the asset owner overwrite\n`asset.Royalties.MarketPercentage` (L670) with only a **per-field** `\u003c= 100%` check (`CheckValid100Params`,\nL651) — it has no knowledge of any outstanding marketplace listing's snapshotted referral. So the\nowner can list at, e.g., referral 100% / royalty 0% (sum 100%, passes `Sell`), then raise royalty to\n100%, making the buy-time sum 200%.\n\n\u003e The shipped emergency-guard source documents this exact vector:\n\u003e *\"The royalty percentage is read live at buy time, so a listing made now can be weaponised later\n\u003e via UpdateRoyalties.\"* (`common/emergencyGuard.go`)\n\n**Net effect:** `referralAmount + royaltiesAmount = bid + bid = 2·bid`; `marketOwnerAmount = −bid`\n(skipped); **`bid` KLV minted per settlement**, paid to attacker-controlled addresses.\n\n---\n\n## Proof of Concept\n\n### A. Committed regression test (deterministic, runnable today)\n`core/kapp/market/market_test.go` — `TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation`.\nIt builds an order with `ReferralPercentage = 100%` and an asset with `MarketPercentage = 100%`\n(the attacker is both the referral and the royalty address), then settles a `bid` of\n`25,600,000 KLV` (`25600000000000` base units):\n\n```bash\ngo test ./core/kapp/market/ -run TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation -v\n```\n\n- `FixDisabled_MintsKLVFromThinAir`: settlement returns `Ok`; the attacker address ends with\n  `2·bid` credited while only `bid` was paid in — i.e. **`bid` KLV minted**.\n- `FixEnabled_RejectsInflation`: with `FixMarketBuyOverflow` on, settlement returns\n  `Transaction_AmountInvalid` and the attacker balance stays `0` — **no payout runs**.\n\n### B. End-to-end on a local node (the real attack path)\nA single-node local network is sufficient. The exploit is four transactions from one ordinary\nfunded account; nothing privileged is required.\n\n1. **Create an NFT collection** you own, with `royalties.marketPercentage = 0` and a royalties\n   address you control.\n2. **Create a marketplace** with `referralPercentage = 10000` (100%) and a referral address you\n   control (`CreateMarketplace`).\n3. **List** one NFT for sale (`Sell`) on that marketplace. The `Sell` check passes because\n   `0 (royalty) + 10000 (referral) = 10000 = HundredPercent`. The order snapshots\n   `ReferralPercentage = 10000`.\n4. **Raise the royalty** on the asset to 100% (`AssetTrigger / UpdateRoyalties`,\n   `marketPercentage = 10000`). Allowed: the per-field check passes and the live combined invariant\n   is never re-evaluated against the open listing.\n5. **Buy** the listing (`MarketBuy`) from a second account (or settle the auction via `Claim`).\n   `referralAmount = bid`, `royaltiesAmount = bid`, `marketOwnerAmount = −bid` (skipped). Your\n   referral + royalty addresses receive `2·bid`; the buyer paid `bid`; **`bid` KLV is minted**.\n\nBecause the attacker controls buyer, seller, referral and royalty addresses, the only real cost is\ntransaction fees; the cycle is repeatable until supply targets are met.\n\n---\n\n## Evidence\n\n### Regression test (local, verbatim)\n```\n=== RUN   TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation\n=== RUN   TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixDisabled_MintsKLVFromThinAir\n=== RUN   TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixEnabled_RejectsInflation\n--- PASS: TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation (0.00s)\n    --- PASS: TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixDisabled_MintsKLVFromThinAir (0.00s)\n    --- PASS: TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation/FixEnabled_RejectsInflation (0.00s)\nPASS\nok  \tgithub.com/klever-io/klever-go/core/kapp/market\t0.279s\n```\n`FixDisabled` asserts the attacker balance equals `2·bid = 51,200,000 KLV` for a single settlement\n(`bid = 25,600,000 KLV`), with `bid` of that minted. `FixEnabled` asserts rejection and a `0`\nbalance.\n\n### Mainnet exploitation (observed)\nThe bug was exploited in production, and was **detected and characterised externally** by the\ncommunity monitoring project **[KleverPuls / kpulse.tech](https://kpulse.tech)** before the root\ncause was known internally. Over a ~24h window kpulse isolated a single wallet (opened\n**2026-06-04**, ~**204 transactions** in ~24h, funded only by a ~**242K KLV KuCoin withdrawal**, no\ntreasury/foundation funding) that:\n\n- **self-issued 3 NFT collections named \"InflationPOC\"** and **wash-traded one (`NFLATION-ESGO/1`)\n  29 times** through self-created marketplaces — ~**$450K of artificial, economically empty NFT\n  volume**;\n- **swapped the proceeds KLV → USDC / USDT / WBTC / WETH on KleverSwap** and **bridged ~$72K of value\n  to Ethereum** via wrapped-asset burns over 24h (USDC −12,487 ≈ $12.5K; USDT −26,362 ≈ $26.4K; WBTC\n  −0.31 ≈ $19.6K; WETH −7.55 ≈ $14K);\n- surfaced a spurious **\"1.86B KLV outflow\"** headline that kpulse correctly identified as a\n  wash-trade **receipt-doubling** artifact with small real net KLV flow.\n\nThat \"doubling of marketplace receipts\" is **precisely the on-chain signature of this bug**: each\nabusive settlement pays out a referral cut (`bid`) **plus** a royalty cut (`bid`) while the buyer paid\nonly `bid` once — the market contract emits ~2× the value it took in, which *is* the mint. The\nattacker's self-issued collection and self-created marketplaces are exactly the self-dealing setup the\nregression test reproduces (the test reuses the real on-chain identifiers: `collectionID =\n\"NFLATION-ESGO\"`, asset `1`, market name \"Inflation Market\").\n\nkpulse could not determine the cause from on-chain data alone and flagged the activity for\nconfirmation; the Klever core team then traced it to the referral+royalty settlement defect described\nabove and shipped the emergency guard + protocol fix.\n\nEach abusive settlement minted one `bid` of KLV; the observed `bid` was `25,600,000 KLV`, repeated and\nfunnelled through a short hop chain before being swapped and bridged. The emergency guard\n(`common/emergencyGuard.go`) blocks the following observed sender public keys (hex):\n\n| Public key (hex) | Address | Role (observed) |\n|---|---|---|\n| `54ea28e527d4136508be955374afa54a8c25c19a48c674f412f7ce02db0f4e1b` | `klv12n4z3ef86sfk2z97j4fhfta9f2xztsv6frr8faqj7l8q9kc0fcdsfjfqez` | root / minter |\n| `bb687dbba23e1844fec674a32cb8809f0d3207506c53fc3d637e40dc56708d63` | `klv1hd58mwaz8cvyflkxwj3jewyqnuxnyp6sd3flc0tr0eqdc4ns343skngdjq` | collector hop (~125M KLV) |\n| `77388d3dfe6cd88e8da723254c11abf3d9cccb6fb77b000e5038fc3ff92b964d` | `klv1wuug6007dnvgard8yvj5cydt70vuejm0kaasqrjs8r7rl7ftjexsglalf6` | direct recipient (25.6M, idle) |\n| `a196789b026f996867f08317cc6c5a4eb9ad3a59b1be3716420bc8692d4c3048` | `klv15xt83xczd7vkselssvtucmz6f6u66wjekxlrw9jzp0yxjt2vxpyq2nawrw` | hop-2 recipient (25M) |\n\nThe single-`bid` per-settlement size (25.6M KLV) matches the \"direct recipient, 25.6M\" entry, and the\n~125M at the collector hop is consistent with roughly five abusive settlements.\n\n---\n\n## Impact\n\n- **Unbounded inflation of KLV** (and of any sale currency used for the listing), repeatable for only\n  transaction fees, by any account that creates its own collection + marketplace.\n- The minted KLV is created by direct `AddToBalance` to attacker addresses (no tracked `Mint`), so\n  the asset's booked supply does not change — the inflation is **off the books** and only detectable\n  by summing balances / auditing receipts (it surfaces on-chain as *doubled* marketplace receipts).\n- **Realized impact (observed):** the attacker minted KLV via ~29 self-dealt settlements, swapped to\n  stable/wrapped assets on KleverSwap, and **off-ramped ~$72K to Ethereum via the bridge** (USDC,\n  USDT, WBTC, WETH) before the emergency guard halted the activity, alongside ~$450K of artificial\n  NFT wash-trade volume.\n- Total loss of economic integrity for all KLV / token holders.\n\n## Who can exploit it / prerequisites\n\n- **Any account** that can pay the one-time collection-create + marketplace-create fees and tx\n  fees. No roles, admin, or allowlist.\n- **Any client.** The settlement is triggered by standard `MarketBuy` / `Claim` contracts POSTed to\n  the public, unauthenticated `/transaction/send` RPC (`network/api/transaction/routes.go`,\n  `SendTX` / `BroadcastTX`). The `operator` CLI, the SDKs, or a hand-signed `curl` all work.\n- Deterministic; the abusive state is reached with one extra `UpdateRoyalties` after a normal listing.\n\n---\n\n## Remediation\n\nShipped as a layered response (embargoed):\n\n### Layer 0 — emergency guard (deployed first, fork-proof) — `GHSA-p7gw` rc1\n`common/emergencyGuard.go` + `data/transaction/emergencyGuard.go`: matching transactions are kept\nout of blocks this node proposes (`core/process/block/preprocess/transactions.go`) and refused at\nthe node API (`node.go` `SendTransaction` / `SendBulkTransactions`). It **never changes block\nvalidity**, so a partial-fleet rollout cannot fork the chain. It blocks the known attacker senders\n(all contract types) plus all `MarketBuy`, `Sell`, and `CreateMarketplace` / `ConfigMarketplace`\noperations while the protocol fix rolls out. Enforcement is by proposer cooperation, not protocol —\ncoverage equals the share of block producers running the guard.\n\n### Layer 1 — protocol fix (consensus, epoch-gated) — `GHSA-p7gw` rc2\n`core/kapp/market/market.go:593` rejects the settlement when `marketOwnerAmount \u003c 0`, **before any\npayout runs**, returning `Transaction_AmountInvalid`. Gated behind the new `FixMarketBuyOverflow`\nactivation-epoch flag (`config/enableEpochs.*`, `core/fork/forks.go`, `core/interface.go`) so\nhistorical blocks reprocess identically. Covered by\n`TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation`.\n\n### Recommended hardening (defense in depth)\n1. **Snapshot the royalty %** into `MarketOrderData` at `Sell` (as referral already is) and pay from\n   the snapshot, eliminating the TOCTOU entirely; or re-evaluate the combined\n   `referral% + royalty% \u003c= 100%` invariant at settlement.\n2. Treat a **negative** seller remainder as a hard error everywhere, and only treat exactly `0` as a\n   no-op skip (`computeMarketOwnerAmount`), so a future regression aborts the tx instead of minting.\n3. After splitting a payment pool, **assert conservation** (`referral + royalties + ownerShare == bid`)\n   so any drift aborts the transaction.\n\n---\n\n## Notes\n\n- Triggered by both BuyItNow (`Buy`) and auction settlement (`Claim`).\n- The same family of \"pay full cut, silently drop the negative remainder\" minting also exists in the\n  royalty-split paths and is tracked separately under **GHSA-cgc5-v3f2-8m2v** (split-royalty `uint32`\n  overflow). This advisory covers the top-level referral+royalty \u003e bid case; the\n  `FixMarketBuyOverflow` guard here only checks `marketOwnerAmount`, not intra-split over-payments.\n\n## Acknowledgments\n\n- **[KleverPuls / kpulse.tech](https://kpulse.tech)** — community monitoring project that **first\n  detected and characterised the exploitation in the wild**. kpulse isolated the attacker wallet and\n  its \"InflationPOC\" collections, identified the marketplace wash-trading of `NFLATION-ESGO/1` and the\n  KleverSwap → bridge off-ramp (~$72K to Ethereum), and flagged the anomalous *doubling* of\n  marketplace receipts — the exact on-chain signature of this bug — prompting the incident response\n  that led to this fix. The root cause was then identified and remediated by the Klever core team.\n\n## Source\n\n- Vulnerable / fixed code: `core/kapp/market/market.go:540-545,575-596,908,997-998`,\n  `core/kapp/kda/trigger.go:613-676`, `core/process/kda/assetHelper.go:101`,\n  `tools/converters.go:102`, `core/constants.go:18`.\n- Emergency guard: `common/emergencyGuard.go`, `data/transaction/emergencyGuard.go`,\n  `core/process/block/preprocess/transactions.go`, `node/node.go`.\n- Fork flag: `config/enableEpochs.go`, `config/node/enableEpochs.yaml`, `core/fork/forks.go`,\n  `core/interface.go`.\n- Regression test: `core/kapp/market/market_test.go`\n  (`TestMarketKApp_ExecuteBuyMarket_RoyaltyReferralInflation`).","status":"published","published":"2026-08-28T16:22:15Z","modified":"2026-09-02T19:41:40.049364951Z","cvss":[{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H","level":"critical"}],"cwes":["CWE-191","CWE-367","CWE-682"],"updated_at":"2026-11-02T15:46:52.891208Z"},{"id":"GO-2026-6315","title":"Klever: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped) in github.com/klever-io/klever-go","description":"Klever: Marketplace settlement mints KLV when referral % + royalty % exceed the bid (negative seller share silently skipped) in github.com/klever-io/klever-go","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:30:09.208568214Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21812-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:52:09Z","modified":"2026-09-10T18:23:18.964541257Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23692-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.31116925Z","updated_at":"2026-11-02T15:54:03.991985Z"},{"id":"SUSE-SU-2026:23712-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.805639295Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}