CVE-2026-49343: klever-go · Uncontrolled Resource Consumption
Affects klever-goSource CVE Database V5
Not known to be exploited · CVSS 5.9 Medium : upgrade to 1.7.18 when convenient.
Data as of 5 Nov 2026, 00:01 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 35% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.7.18
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 7 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.
What to do
Upgrade klever-go and github.com/klever-io/klever-go to 1.7.18.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| klever-ioklever-go | Affected
| Fixed in
|
Gogithub.com/klever-io/klever-gopkg:golang/github.com/klever-io/klever-goOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Upgrade Klever-Go to version 1.7.18 or later, where this resource exhaustion issue is fixed. Patch status is confirmed by the vendor stating the fix in 1.7.18. No other mitigations are indicated.
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.