CVE-2026-49343: Klever-Go KVM Denial of Service Vulnerability
MODERATECVE-2026-49343 is a MODERATE (CVSS 5.9) denial of service vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting Klever-Go KVM libraries in the Go ecosystem. The issue involves throttler slot leak in trie account-data sync causes epoch bootstrap / state sync dos. Remediation is available by upgrading affected packages to version 1.7.18.
CVE-2026-49343 at a Glance
Security Impact
CVSS: 5.9
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).
How to Fix CVE-2026-49343
To remediate this vulnerability, upgrade all affected Klever-Go KVM dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade github.com/klever-io/klever-go to 1.7.18
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for github.com/klever-io/klever-go
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-49343, inspect your project dependencies for Klever-Go KVM:
inspect dependencies for github.com/klever-io/klever-go
Analyze the terminal output to locate any version of Klever-Go KVM in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.7.18), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. In Klever-Go KVM, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-49343 Affected Klever-Go KVM Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
github.com/klever-io/klever-go
|
Go |
< 1.7.18
|
1.7.18
|
References
Frequently Asked Questions
What is CVE-2026-49343?
Which Klever-Go KVM versions are affected?
What version fixes CVE-2026-49343?
Is github.com/klever-io/klever-go affected?
What is the CVSS score of CVE-2026-49343?
What CWE is associated with CVE-2026-49343?
How can I check Go dependencies for CVE-2026-49343?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-fw38-pc54-jvx9",
"modified" : "2026-06-05T16:40:40Z",
"published" : "2026-06-05T16:40:40Z",
"aliases" : [ "CVE-2026-49343" ],
"summary" : "Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS",
"details" : "## Summary\n\n The account-data trie syncers leak bounded throttler slots on error paths in `syncDataTrie()`. Each failed trie sync permanently consumes one slot from\n the `NumGoRoutinesThrottler`, and the slot is never returned unless the sync succeeds or the root hash was already present.\n\n I confirmed this on the current default branch `develop` at commit `9640d63` (observed on May 20, 2026). I also confirmed the bug with a runtime PoC\n using the real timeout path in `trieSyncer.StartSyncing()`: two timed-out sync attempts are enough to exhaust a throttler with capacity `2`.\n\n This affects the epoch bootstrap path because `syncUserAccountsState()` and `syncKappAccountsState()` create bounded throttlers and abort bootstrap\n immediately if the syncer returns an error. Once enough trie-root sync attempts fail, the syncer cannot make forward progress and bootstrap fails.\n\n ## Affected Components\n\n - `data/syncer/userAccountsSyncer.go`\n - `data/syncer/kappAccountsSyncer.go`\n - `data/trie/sync.go`\n - `core/throttler/numGoRoutinesThrottler.go`\n - `core/bootstrap/process.go`\n\n ## Affected Version\n\n Verified on:\n - `develop` HEAD `9640d63`\n\n Please check whether the same code is present in supported `1.7.x` releases.\n\n ## Suggested Severity\n\n High\n\n ## Vulnerability Details\n\n ### Root Cause\n\n Both account-data syncers call `StartProcessing()` before creating / starting the trie syncer, but they only call `EndProcessing()` on the success path\n and on the duplicate-root early return.\n\n `userAccountsSyncer.syncDataTrie()`:\n\n ```go\n func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error {\n u.throttler.StartProcessing()\n\n u.syncerMutex.Lock()\n if _, ok := u.dataTries[string(rootHash)]; ok {\n u.syncerMutex.Unlock()\n u.throttler.EndProcessing()\n return nil\n }\n\n dataTrie, err := trie.NewTrie(...)\n if err != nil {\n u.syncerMutex.Unlock()\n return err\n }\n\n trieSyncer, err := trie.NewTrieSyncer(arg)\n if err != nil {\n u.syncerMutex.Unlock()\n return err\n }\n\n u.syncerMutex.Unlock()\n\n err = trieSyncer.StartSyncing(rootHash, ctx)\n if err != nil {\n return err\n }\n\n u.throttler.EndProcessing()\n return nil\n }\n\n The same bug exists in kappAccountsSyncer.syncDataTrie().\n```\n ### Missing slot release paths\n\n After StartProcessing(), the following error paths return without EndProcessing():\n\n 1. trie.NewTrie(...) returns an error\n 2. trie.NewTrieSyncer(...) returns an error\n 3. trieSyncer.StartSyncing(...) returns an error\n\n ### Why this matters\n\n NumGoRoutinesThrottler is a strict bounded counter:\n```\n func (ngrt *NumGoRoutinesThrottler) CanProcess() bool {\n valCounter := atomic.LoadInt32(&ngrt.counter)\n return valCounter < ngrt.max\n }\n\n func (ngrt *NumGoRoutinesThrottler) StartProcessing() {\n atomic.AddInt32(&ngrt.counter, 1)\n }\n\n func (ngrt *NumGoRoutinesThrottler) EndProcessing() {\n atomic.AddInt32(&ngrt.counter, -1)\n }\n\n Once leaked, a slot remains consumed for the lifetime of that throttler instance.\n\n The parent loops in both syncers wait for capacity before starting the next account-data trie sync:\n\n for !u.throttler.CanProcess() {\n select {\n case <-time.After(timeBetweenRetries):\n continue\n case <-ctx.Done():\n return common.ErrTimeIsOut\n }\n }\n```\n So after enough failures, further roots stop progressing and the sync operation eventually returns time is out.\n\n ### Bootstrap impact\n\n Epoch bootstrap uses these syncers directly and aborts on any error:\n```\n err = e.syncUserAccountsState(e.epochStartMeta.Header.TrieRoot)\n if err != nil {\n return nil, nil, err\n }\n\n err = e.syncKappAccountsState(e.epochStartMeta.Header.KAppsTrieRoot)\n if err != nil {\n return nil, nil, err\n }\n```\n The throttlers for these paths are real bounded throttlers created from numConcurrentTrieSyncers.\n\n ## Proof of Concept\n\n I verified the bug with the real timeout path, not only with a canceled context.\n\n The PoC below uses:\n\n - a real NumGoRoutinesThrottler with capacity 2\n - a real trieSyncer.StartSyncing()\n - an empty trie-node cache and a request handler that never supplies nodes\n - a short sync timeout (1s) so StartSyncing() returns trie.ErrTimeIsOut\n\n After the first failed sync, one slot remains leaked.\n After the second failed sync, the throttler is exhausted.\n\n ### PoC test\n```\n package syncer\n\n import (\n \"context\"\n \"testing\"\n \"time\"\n\n commonmock \"github.com/klever-io/klever-go/common/mock\"\n corethrottler \"github.com/klever-io/klever-go/core/throttler\"\n \"github.com/klever-io/klever-go/data\"\n \"github.com/klever-io/klever-go/data/trie\"\n triestats \"github.com/klever-io/klever-go/data/trie/statistics\"\n \"github.com/stretchr/testify/require\"\n )\n\n func newBaseSyncerForTimeoutPOC(t *testing.T) *baseAccountsSyncer {\n t.Helper()\n\n storageManager, err := trie.NewTrieStorageManagerWithoutPruning(commonmock.NewMemDbMock())\n require.NoError(t, err)\n\n return &baseAccountsSyncer{\n hasher: commonmock.HasherMock{},\n marshalizer: &commonmock.MarshalizerMock{},\n trieSyncers: make(map[string]data.TrieSyncer),\n dataTries: make(map[string]data.Trie),\n trieStorageManager: storageManager,\n requestHandler: &commonmock.RequestHandlerStub{},\n timeout: time.Second,\n cacher: commonmock.NewCacherStub(),\n maxTrieLevelInMemory: 5,\n name: \"timeout-poc\",\n maxHardCapForMissingNodes: 1,\n }\n }\n\n func TestPOC_UserAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) {\n thr, err := corethrottler.NewNumGoRoutinesThrottler(2)\n require.NoError(t, err)\n\n s := &userAccountsSyncer{\n baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),\n throttler: thr,\n }\n\n err = s.syncDataTrie([]byte(\"missing-root-1\"), triestats.NewTrieSyncStatistics(), context.Background())\n require.ErrorIs(t, err, trie.ErrTimeIsOut)\n require.True(t, thr.CanProcess())\n\n err = s.syncDataTrie([]byte(\"missing-root-2\"), triestats.NewTrieSyncStatistics(), context.Background())\n require.ErrorIs(t, err, trie.ErrTimeIsOut)\n require.False(t, thr.CanProcess())\n }\n\n func TestPOC_KappAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) {\n thr, err := corethrottler.NewNumGoRoutinesThrottler(2)\n require.NoError(t, err)\n\n s := &kappAccountsSyncer{\n baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),\n throttler: thr,\n }\n\n err = s.syncDataTrie([]byte(\"missing-root-1\"), triestats.NewTrieSyncStatistics(), context.Background())\n require.ErrorIs(t, err, trie.ErrTimeIsOut)\n require.True(t, thr.CanProcess())\n\n err = s.syncDataTrie([]byte(\"missing-root-2\"), triestats.NewTrieSyncStatistics(), context.Background())\n require.ErrorIs(t, err, trie.ErrTimeIsOut)\n require.False(t, thr.CanProcess())\n }\n```\n ### Command used\n```\n go test ./data/syncer -run 'TestPOC_(User|Kapp)AccountsSyncer_LeaksThrottlerSlotOnTrieTimeout' -count=1\n```\n ### Result\n```\n ok github.com/klever-io/klever-go/data/syncer 4.005s\n```\n This confirms the leak with the real timeout path from trieSyncer.StartSyncing().\n\n ## Impact\n\n An attacker who can repeatedly cause trie-node sync failures or timeouts during bootstrap can consume the bounded sync throttler until no capacity\n remains.\n\n Once enough slots are leaked:\n\n - additional account-data trie sync attempts stop making progress\n - the parent loop waits until context timeout\n - SyncAccounts() fails\n - epoch bootstrap fails\n\n This is a core node availability issue. It affects fresh/restarting nodes and validators that need to bootstrap or resync state.\n\n This is not a theoretical issue:\n\n - StartSyncing() performs network-dependent trie-node retrieval\n - it already has explicit timeout / failure paths\n - the leaked throttler slots are confirmed by runtime PoC\n\n ## Recommended Fix\n\n Release the slot with defer immediately after StartProcessing() and cancel the defer only if ownership is intentionally transferred, which is not the\n case here.\n\n Example fix pattern:\n```\n func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error {\n u.throttler.StartProcessing()\n defer u.throttler.EndProcessing()\n\n u.syncerMutex.Lock()\n defer u.syncerMutex.Unlock()\n\n if _, ok := u.dataTries[string(rootHash)]; ok {\n return nil\n }\n\n dataTrie, err := trie.NewTrie(...)\n if err != nil {\n return err\n }\n\n trieSyncer, err := trie.NewTrieSyncer(arg)\n if err != nil {\n return err\n }\n\n u.trieSyncers[string(rootHash)] = trieSyncer\n return trieSyncer.StartSyncing(rootHash, ctx)\n }\n```\n The same pattern should be applied to:\n\n - data/syncer/userAccountsSyncer.go\n - data/syncer/kappAccountsSyncer.go\n\n ## References\n\n - data/syncer/userAccountsSyncer.go\n - data/syncer/kappAccountsSyncer.go\n - data/trie/sync.go\n - core/throttler/numGoRoutinesThrottler.go\n - core/bootstrap/process.go\n - SECURITY.md",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Go",
"name" : "github.com/klever-io/klever-go"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "1.7.18"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/klever-io/klever-go"
}, {
"type" : "WEB",
"url" : "https://github.com/klever-io/klever-go/releases/tag/v1.7.18"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-400", "CWE-772" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-06-05T16:40:40Z",
"nvd_published_at" : null
}
}