CVE-2026-49343 in klever-go
Summary
by MITRE • 08/08/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/08/2026
The Klever-Go blockchain implementation contains a critical resource exhaustion vulnerability in its account-data trie synchronization mechanism that affects versions prior to 1.7.18. This flaw resides in the throttler management system used to control concurrent trie synchronization operations, creating a persistent resource leak that ultimately leads to complete synchronization failure. The vulnerability specifically impacts the syncDataTrie() function implementations in both userAccountsSyncer.go and kappAccountsSyncer.go files where the throttling mechanism fails to properly release resources on error conditions.
The technical flaw manifests through improper resource management within the NumGoRoutinesThrottler system where StartProcessing() acquires a slot from the throttler pool but EndProcessing() is only invoked on successful execution paths or when duplicate roots are encountered early in processing. When trie operations such as trie.NewTrie(), trie.NewTrieSyncer(), or trieSyncer.StartSyncing() encounter failures including network timeouts, the system permanently consumes throttler slots without releasing them back to the pool. This creates a progressive depletion of available concurrent execution slots that directly impacts the node's ability to process account data trie synchronization requests.
The operational impact of this vulnerability extends beyond simple performance degradation to constitute a complete availability failure for blockchain nodes during critical bootstrap operations. During epoch bootstrap procedures in syncUserAccountsState() and syncKappAccountsState(), any trie synchronization error or timeout causes the system to abort the entire bootstrap process rather than attempting recovery or retry mechanisms. This results in fresh node startups, validator restarts, or network resynchronization attempts failing completely, effectively preventing nodes from joining or rejoining the blockchain network.
The vulnerability aligns with CWE-400 weakness category related to resource exhaustion and demonstrates characteristics consistent with ATT&CK technique T1499.002 for network denial of service. The flaw represents a classic example of improper resource cleanup in concurrent programming where error handling paths fail to maintain system state consistency. Attackers can exploit this by repeatedly triggering trie-node synchronization failures or timeouts during bootstrap phases, systematically consuming all available throttler slots until no further synchronization operations can proceed. The fix implemented in version 1.7.18 addresses the root cause by ensuring EndProcessing() is called on all execution paths including error conditions, thereby properly releasing throttler slots back to the available pool and maintaining system availability during critical bootstrap operations.
This vulnerability demonstrates the critical importance of proper resource management in distributed systems where concurrent operation and error recovery must maintain system integrity. The issue affects core blockchain functionality by creating a cascading failure scenario where initial synchronization problems propagate to prevent any further progress, ultimately rendering nodes incapable of participating in network consensus or maintaining valid chain state. The fix ensures that throttler resources are properly managed regardless of execution path, preventing attackers from exploiting this weakness to create persistent denial-of-service conditions against Klever-Go nodes and validators.