https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 20:05:39 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-55763 <p>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 &lt;= 0 early return. computeSplitRoyalties rejects only when splitToPay &gt; 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&#39;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.</p> <p>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 &lt;= 0 early return. computeSplitRoyalties rejects only when splitToPay &gt; 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&#39;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.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-55763 https://vulnerability.circl.lu/vuln/ghsa-v358-wf77-39xv <p><strong>Affected:</strong> Go: github.com/klever-io/klever-go</p> <p>## Summary In `processPercentageRoyaltiesTransfer` the royalty pool is collected from the sender by `SubFromBalance` that is ordered **after** the split loop and after `if royaltiesToPay &lt;= 0 { return Ok }`. The split-payout guard rejects only an allocation that *exceeds* the pool (a strict `splitToPay &gt; royaltiesToPay`), so a split entry of **exactly 100%** (`PercentTransferPercentage = 10000`) is a *valid* config: it drives `royaltiesToPay` to 0 and hits the early-return **before** the sender is debited. The split recipient keeps the full royalty; the sender pays nothing for it → mint. The sibling fixed-royalty path (`processFixedRoyaltiesTransfer`) debits the sender **first** and is safe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after the early-return.</p> <p>## Affected code - `core/kapp/accounts/accounts.go` — `processPercentageRoyaltiesTransfer`: split loop → `if royaltiesToPay &lt;= 0 { return Ok }` → `acntSrc.SubFromBalance(royaltyAmount)` (debit after the early-return). Contrast the safe `processFixedRoyaltiesTransfer` (debit before the loop).</p> <p>## Impact Unbounded self-inflation of the transferred KDA: `royaltyAmount = transferValue × rate` is minted to an owner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update (off-the-books).</p> <p>## Reachability Owner-gated to configure (own KDA with a `TransferPercentage` royalty + a 100% split). Once configured, the mi…</p> <p><strong>Affected:</strong> Go: github.com/klever-io/klever-go</p> <p>## Summary In `processPercentageRoyaltiesTransfer` the royalty pool is collected from the sender by `SubFromBalance` that is ordered **after** the split loop and after `if royaltiesToPay &lt;= 0 { return Ok }`. The split-payout guard rejects only an allocation that *exceeds* the pool (a strict `splitToPay &gt; royaltiesToPay`), so a split entry of **exactly 100%** (`PercentTransferPercentage = 10000`) is a *valid* config: it drives `royaltiesToPay` to 0 and hits the early-return **before** the sender is debited. The split recipient keeps the full royalty; the sender pays nothing for it → mint. The sibling fixed-royalty path (`processFixedRoyaltiesTransfer`) debits the sender **first** and is safe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after the early-return.</p> <p>## Affected code - `core/kapp/accounts/accounts.go` — `processPercentageRoyaltiesTransfer`: split loop → `if royaltiesToPay &lt;= 0 { return Ok }` → `acntSrc.SubFromBalance(royaltyAmount)` (debit after the early-return). Contrast the safe `processFixedRoyaltiesTransfer` (debit before the loop).</p> <p>## Impact Unbounded self-inflation of the transferred KDA: `royaltyAmount = transferValue × rate` is minted to an owner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update (off-the-books).</p> <p>## Reachability Owner-gated to configure (own KDA with a `TransferPercentage` royalty + a 100% split). Once configured, the mi…</p> https://vulnerability.circl.lu/vuln/ghsa-v358-wf77-39xv