CVE-2026-55764: Integer Overflow in SFT Circulation Counter in Klever-Go

The vulnerability CVE-2026-55764 is an integer overflow or wraparound (CWE-190) in the Semi-Fungible Token (SFT) implementation of the klever-go repository. The klever-go application serves as the core Go-based node software for the Klever blockchain protocol. The flaw specifically manifests within the SFT quantity addition transaction path, which is handled by the system KApp module.

An attacker who holds the required authorization (specifically the mint-role) on a specific SFT asset can issue a transaction to add an excessively large quantity of tokens to the circulation. Because the system performs standard addition using signed 64-bit integers (int64) without overflow boundaries, the addition of a high positive number causes the counter to exceed the maximum value limit. This mathematical behavior results in a signed integer wraparound, altering the circulation tracking variable into a highly negative number.

Once the circulation counter wraps into a negative range, the subsequent business logic check designed to restrict total token creation fails to recognize the violation. The logic is programmed to compare the updated circulation against a positive maximum supply ceiling. Because any negative integer is mathematically less than any positive integer, the verification is bypassed, committing the anomalous state modification to the decentralized ledger.

While classic application memory vulnerabilities might lead to direct shell execution, this state manipulation bug bypasses consensus rules. The primary impact is the unauthorized inflation of digital assets beyond their designated ceiling, paired with the corruption of the global state-trie storage. Additionally, reading corrupted metrics via concurrent API calls introduces secondary denial-of-service vectors.

To understand the root cause of the vulnerability, we must examine how Go evaluates arithmetic operations on signed integers. A signed 64-bit integer (int64) utilizes two's complement representation, allocating one bit for the sign and 63 bits for the magnitude. The maximum positive value representable by this type is 9,223,372,036,854,775,807 (0x7fffffffffffffff), while the lowest negative value is -9,223,372,036,854,775,808 (0x8000000000000000).

When klever-go processes an SFT quantity addition via the SFTAddCirculation function in core/kapp/systemAccount/systemAcount.go, it executes the following instruction:

meta.Circulation += amount

If the asset's existing on-chain circulation tracker holds a positive value (for instance, 1,000) and the transaction specifies an addition amount equal to or close to math.MaxInt64, the CPU performs the operation directly. The resulting binary addition overflows the 63-bit magnitude limit, setting the sign bit to 1. Consequently, the state tracker meta.Circulation transitions to a value such as -9,223,372,036,854,774,809.

The logic then validates whether the updated value complies with the configured limit of the asset:

if meta.Circulation > meta.MaxSupply && meta.MaxSupply != 0 {
    return common.ErrMaxSupplyExceeded
}

Since meta.MaxSupply is set to a legitimate positive upper boundary, the evaluation compares a highly negative number against a positive number. Because the expression -9,223,372,036,854,774,809 > MaxSupply evaluates to false, the conditional body is skipped, and the code returns no error. The system commits the transaction, and the corrupted value propagates directly into the state trie database.

The vulnerability is located in core/kapp/systemAccount/systemAcount.go. Below is a comparison between the original vulnerable code block and the corrected implementation in version 1.7.19.

Vulnerable Implementation

In the original version, the SFTAddCirculation function did not perform safety audits on the arithmetic addition. The operation was performed blindly, followed by a signed inequality check:

func (s *systemAccountKApp) SFTAddCirculation(asset, nonce []byte, amount int64) error {
	// Load the existing SFT metadata from the database
	meta, err := s.SFTGetMeta(asset, nonce)
	if err != nil {
		return err
	}
 
	// VULNERABILITY: Blind addition on signed int64 can overflow/wrap around
	meta.Circulation += amount
 
	log.Trace("SFTAddCirculation", "max supply", meta.MaxSupply, "value", meta.Circulation)
 
	// Bypassed if meta.Circulation wraps to a negative value
	if meta.Circulation > meta.MaxSupply && meta.MaxSupply != 0 {
		return common.ErrMaxSupplyExceeded
	}
 
	// Save the corrupted meta back to the ledger
	return s.SFTSaveMeta(asset, nonce, meta)
}

Patched Implementation

The fix, introduced in commit 8bcc600b0ac88070740c63c7ce1c8a968dd85251, resolves this by checking if the resulting value is smaller than the previous value when a positive amount is added. Crucially, the check is gated by a fork controller:

func (s *systemAccountKApp) SFTAddCirculation(asset, nonce []byte, amount int64) error {
	// Load the existing SFT metadata from the database
	meta, err := s.SFTGetMeta(asset, nonce)
	if err != nil {
		return err
	}
 
	// Store the current state prior to addition to permit differential analysis
	previousCirculation := meta.Circulation
	meta.Circulation += amount
 
	log.Trace("SFTAddCirculation", "max supply", meta.MaxSupply, "value", meta.Circulation)
 
	// Gated check to prevent breaking backwards compatibility during historical block replay
	if s.forkController.FixMarketBuyOverflow() && amount > 0 && meta.Circulation < previousCirculation {
		return common.ErrMaxSupplyExceeded
	}
 
	if meta.Circulation > meta.MaxSupply && meta.MaxSupply != 0 {
		return common.ErrMaxSupplyExceeded
	}
 
	return s.SFTSaveMeta(asset, nonce, meta)
}

By comparing meta.Circulation < previousCirculation, the engine identifies whether an addition operation caused the value to wrap backwards. This is an efficient check for detecting signed integer overflow. Furthermore, gating the logic with s.forkController.FixMarketBuyOverflow() allows the blockchain engine to maintain historical consensus. When replaying blocks that occurred before the hard-fork activation height, the check is skipped to avoid consensus mismatches, but is strictly enforced on all subsequent blocks.

Exploitation of CVE-2026-55764 requires a specific execution context. First, the attacker must have authorization to call the SFT minting or quantity addition actions. In a standard deployment of the Klever blockchain protocol, this means controlling the cryptographic key pair that holds the mint-role privilege for a targeted SFT asset.

The attack begins with the construction of a custom processSemiFungibleAddQuantity transaction payload. The attacker must select a target SFT that restricts supply using a finite, non-zero MaxSupply ceiling. If the current circulation of this SFT is represented as $C$, the attacker determines the targeted overflow value $A$ such that the sum of the current circulation and the addition amount overflows the signed 64-bit bounds ($C + A >= 2^{63}$).

When the malicious transaction is broadcast, the block-producing node accepts it into the pool and processes it in the state engine. Because the validation evaluates to false when checking the wrapped negative circulation value, the transaction successfully executes. This bypass results in the creation of massive amounts of the target asset on-chain while concurrently writing a corrupted negative balance into the account database, which disrupts indexers and client queries.

The security implications of CVE-2026-55764 are concentrated around consensus integrity and service availability. On a blockchain ledger, the unauthorized creation of SFT assets directly compromises the trust model and the tokenomics of the underlying network. This allows an attacker to inflate assets "out of thin air," bypassing hardcoded scarcity limits and destabilizing the balance configuration of SFT-related markets.

Beyond direct token inflation, the vulnerability presents a significant availability risk to node infrastructure. Writing a negative number into the state trie database causes computational anomalies for downstream components. When client endpoints, APIs, and external search indexers (such as the Elasticsearch indexer) read these state values, they execute database requests that trigger concurrent map read/write data races in Go's memory space. This memory state inconsistency causes the blockchain daemon to panic and crash immediately, degrading the overall availability of the network.

This behavior explains the CVSS v4.0 rating of 8.7, which specifies a High (H) availability impact. Although confidentiality is unaffected, the threat of persistent node crashes due to corrupted state lookups poses a severe risk to validators. The threat vector is remote, requirements are low, and exploitation requires no user interaction, highlighting the critical nature of implementing the patch on active validators.

The primary remediation path is upgrading the node runtime to Klever-Go version 1.7.19 or higher. This release contains the updated arithmetic validations in SFTAddCirculation and the FixMarketBuyOverflow consensus fork controller. Node operators must upgrade prior to the activation epoch designated for the consensus hard fork to prevent their nodes from falling out of sync with the rest of the network.

Configuration Updates

Operators must ensure that their node configuration file, typically named enableEpochs.yaml, contains the necessary parameters to activate the mitigation at the chosen epoch. The line should be added as follows:

enableEpochs:
  fixMarketBuyOverflow: <Target_Activation_Epoch>

Detection and Auditing

Security teams and infrastructure auditors can query internal indexing databases to identify whether the overflow has been historically triggered on-chain. Since the Elasticsearch indexer might process and store these values, a targeted range query can reveal any anomalous negative circulation balances across all SFT records:

GET /sft-metadata-index/_search
{
  "query": {
    "range": {
      "circulation": {
        "lt": 0
      }
    }
  }
}

If any document matches the query, it indicates that an SFT asset's circulation counter has successfully wrapped into the negative range, proving that an overflow transaction was executed. Immediate manual state reconstruction is required to reverse the unauthorized balance additions in such cases.