Description

Klever-Go is the Go implementation of the Klever blockchain protocol. In versions prior to 1.7.18, the account-data trie syncers are vulnerable to a resource-exhaustion flaw that leaks bounded throttler slots on error paths. In syncDataTrie() (in both userAccountsSyncer.go and kappAccountsSyncer.go), StartProcessing() reserves a slot from the NumGoRoutinesThrottler, but the corresponding EndProcessing() is only called on the success path and on the duplicate-root early return. As a result, any error from trie.NewTrie(), trie.NewTrieSyncer(), or trieSyncer.StartSyncing() (including the network-dependent timeout path) permanently consumes one slot for the lifetime of the throttler. An attacker who can repeatedly cause trie-node sync failures or timeouts during bootstrap can exhaust the bounded throttler, after which further account-data trie syncs stop making progress and SyncAccounts() returns a timeout. Because epoch bootstrap in syncUserAccountsState() and syncKappAccountsState() aborts on any such error, this causes bootstrap to fail, a core availability issue affecting fresh, restarting, or resyncing nodes and validators. This issue is fixed in version 1.7.18.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-07T23:17:04.450Z",
  "pubdate": "2026-08-07T23:17:04.450Z",
  "executiveSummary": "A resource-exhaustion vulnerability exists in the account-data trie syncers of Klever-Go versions prior to 1.7.18. The flaw involves leaked bounded throttler slots on error execution paths within the state synchronization logic. Specifically, the synchronization functions reserve concurrency slots via the NumGoRoutinesThrottler but fail to release them when encountering specific initialization or synchronization errors.\nThis vulnerability leads to a denial of service affecting core node availability. An attacker capable of repeatedly triggering trie-node synchronization failures or network timeouts during the node bootstrap phase can permanently consume all available throttler slots. Once exhausted, subsequent account-data trie synchronization attempts stall permanently, causing bootstrap procedures to fail and preventing fresh, restarting, or resyncing validators and nodes from joining or maintaining network consensus.\nThe attack requires network interaction capable of inducing trie synchronization failures or timeouts during the bootstrapping process. The vulnerability directly impacts system availability by permanently exhausting constrained internal concurrency resources, requiring an upgrade to version 1.7.18 to remediate the underlying flaw.",
  "technicalDetails": "The vulnerability stems from improper resource management and error handling within the syncDataTrie() function, implemented across userAccountsSyncer.go and kappAccountsSyncer.go in Klever-Go versions prior to 1.7.18. During the execution of syncDataTrie(), the component calls StartProcessing(), which successfully reserves a concurrency slot from the internal NumGoRoutinesThrottler.\nUnder normal execution or specific duplicate-root early return conditions, the corresponding EndProcessing() function is correctly invoked to release the reserved slot back to the throttler pool. However, on error paths originating from trie.NewTrie(), trie.NewTrieSyncer(), or trieSyncer.StartSyncing()—including network-dependent timeout scenarios—the execution flow bypasses the invocation of EndProcessing().\nConsequently, any error encountered during these initialization or synchronization phases results in a permanent leak of a throttler slot for the entire lifetime of the throttler instance. The attack flow involves an adversary repeatedly generating conditions that force trie-node synchronization failures or triggering timeouts during the node bootstrap phase. Each failed attempt permanently consumes a bounded throttler slot.\nAs the attacker exhausts the remaining slots, further account-data trie sync operations are completely blocked from making forward progress, causing SyncAccounts() to return a timeout. Because the epoch bootstrap processes in syncUserAccountsState() and syncKappAccountsState() are designed to abort upon encountering such failures, the node fails its bootstrap sequence entirely. This presents a severe availability vector targeting fresh nodes, restarting nodes, and active validators on the network.\nThe affected components comprise the account-data trie syncer modules utilizing NumGoRoutinesThrottler across the specified source files. Exploitation does not require authentication or elevated privileges, relying solely on network exposure capable of influencing synchronization responses or inducing timeouts during the state bootstrapping phase."
}