Vulnerability-Lookup

CVE-2026-49343 (GCVE-0-2026-49343)

Vulnerability from cvelistv5 – Published: 2026-08-07 22:18 – Updated: 2026-08-13 18:40

Title

Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS

Summary

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.

Severity

5.9 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-13 18:40 UTC

CWE

CWE-400 - Uncontrolled Resource Consumption
CWE-772 - Missing Release of Resource after Effective Lifetime

Assigner

GitHub_M

References

2 references

URL	Tags
https://github.com/klever-io/klever-go/security/a…	x_refsource_CONFIRM
https://github.com/klever-io/klever-go/releases/t…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
klever-io	klever-go	Affected: < 1.7.18

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-49343",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-13T18:40:07.764602Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-13T18:40:16.330Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "klever-go",
          "vendor": "klever-io",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.7.18"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 5.9,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400: Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-772",
              "description": "CWE-772: Missing Release of Resource after Effective Lifetime",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-07T22:18:18.735Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9"
        },
        {
          "name": "https://github.com/klever-io/klever-go/releases/tag/v1.7.18",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.18"
        }
      ],
      "source": {
        "advisory": "GHSA-fw38-pc54-jvx9",
        "discovery": "UNKNOWN"
      },
      "title": "Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-49343",
    "datePublished": "2026-08-07T22:18:18.735Z",
    "dateReserved": "2026-05-29T14:35:45.903Z",
    "dateUpdated": "2026-08-13T18:40:16.330Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-49343",
      "date": "2026-08-16",
      "epss": "0.00264",
      "percentile": "0.18445"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-49343\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-08-07T23:17:04.450\",\"lastModified\":\"2026-08-13T19:17:22.610\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"klever-io\",\"product\":\"klever-go\",\"versions\":[{\"version\":\"\u003c 1.7.18\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.9,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":2.2,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-08-13T18:40:07.764602Z\",\"id\":\"CVE-2026-49343\",\"options\":[{\"exploitation\":\"poc\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-400\"},{\"lang\":\"en\",\"value\":\"CWE-772\"}]}],\"references\":[{\"url\":\"https://github.com/klever-io/klever-go/releases/tag/v1.7.18\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-08-08T23:29:43Z",
      "cve": "CVE-2026-49343",
      "id": "CVE-2026-49343",
      "initial_release_date": "2026-07-30T16:43:49Z",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-49343",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-49343.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-49343\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-08-13T18:40:07.764602Z\"}}}], \"references\": [{\"url\": \"https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-08-13T18:39:49.603Z\"}}], \"cna\": {\"title\": \"Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS\", \"source\": {\"advisory\": \"GHSA-fw38-pc54-jvx9\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.9, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"klever-io\", \"product\": \"klever-go\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 1.7.18\"}]}], \"references\": [{\"url\": \"https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9\", \"name\": \"https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/klever-io/klever-go/releases/tag/v1.7.18\", \"name\": \"https://github.com/klever-io/klever-go/releases/tag/v1.7.18\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-400\", \"description\": \"CWE-400: Uncontrolled Resource Consumption\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-772\", \"description\": \"CWE-772: Missing Release of Resource after Effective Lifetime\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-08-07T22:18:18.735Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-49343\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-13T18:40:16.330Z\", \"dateReserved\": \"2026-05-29T14:35:45.903Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-08-07T22:18:18.735Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-FW38-PC54-JVX9

Vulnerability from github – Published: 2026-06-05 16:40 – Updated: 2026-06-05 16:40

Summary

Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS

Details

Summary

The account-data trie syncers leak bounded throttler slots on error paths in syncDataTrie(). Each failed trie sync permanently consumes one slot from the NumGoRoutinesThrottler, and the slot is never returned unless the sync succeeds or the root hash was already present.

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 using the real timeout path in trieSyncer.StartSyncing(): two timed-out sync attempts are enough to exhaust a throttler with capacity 2.

This affects the epoch bootstrap path because syncUserAccountsState() and syncKappAccountsState() create bounded throttlers and abort bootstrap immediately if the syncer returns an error. Once enough trie-root sync attempts fail, the syncer cannot make forward progress and bootstrap fails.

## Affected Components

data/syncer/userAccountsSyncer.go
data/syncer/kappAccountsSyncer.go
data/trie/sync.go
core/throttler/numGoRoutinesThrottler.go
core/bootstrap/process.go

## Affected Version

Verified on: - develop HEAD 9640d63

Please check whether the same code is present in supported 1.7.x releases.

## Suggested Severity

High

## Vulnerability Details

### Root Cause

Both account-data syncers call StartProcessing() before creating / starting the trie syncer, but they only call EndProcessing() on the success path and on the duplicate-root early return.

userAccountsSyncer.syncDataTrie():

```go func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error { u.throttler.StartProcessing()

  u.syncerMutex.Lock()
  if _, ok := u.dataTries[string(rootHash)]; ok {
      u.syncerMutex.Unlock()
      u.throttler.EndProcessing()
      return nil
  }

  dataTrie, err := trie.NewTrie(...)
  if err != nil {
      u.syncerMutex.Unlock()
      return err
  }

  trieSyncer, err := trie.NewTrieSyncer(arg)
  if err != nil {
      u.syncerMutex.Unlock()
      return err
  }

  u.syncerMutex.Unlock()

  err = trieSyncer.StartSyncing(rootHash, ctx)
  if err != nil {
      return err
  }

  u.throttler.EndProcessing()
  return nil

}

The same bug exists in kappAccountsSyncer.syncDataTrie().

  ### Missing slot release paths

  After StartProcessing(), the following error paths return without EndProcessing():

  1. trie.NewTrie(...) returns an error
  2. trie.NewTrieSyncer(...) returns an error
  3. trieSyncer.StartSyncing(...) returns an error

  ### Why this matters

  NumGoRoutinesThrottler is a strict bounded counter:

func (ngrt *NumGoRoutinesThrottler) CanProcess() bool { valCounter := atomic.LoadInt32(&ngrt.counter) return valCounter < ngrt.max }

func (ngrt *NumGoRoutinesThrottler) StartProcessing() { atomic.AddInt32(&ngrt.counter, 1) }

func (ngrt *NumGoRoutinesThrottler) EndProcessing() { atomic.AddInt32(&ngrt.counter, -1) }

Once leaked, a slot remains consumed for the lifetime of that throttler instance.

The parent loops in both syncers wait for capacity before starting the next account-data trie sync:

for !u.throttler.CanProcess() { select { case <-time.After(timeBetweenRetries): continue case <-ctx.Done(): return common.ErrTimeIsOut } }

  So after enough failures, further roots stop progressing and the sync operation eventually returns time is out.

  ### Bootstrap impact

  Epoch bootstrap uses these syncers directly and aborts on any error:

err = e.syncUserAccountsState(e.epochStartMeta.Header.TrieRoot) if err != nil { return nil, nil, err }

err = e.syncKappAccountsState(e.epochStartMeta.Header.KAppsTrieRoot) if err != nil { return nil, nil, err }

  The throttlers for these paths are real bounded throttlers created from numConcurrentTrieSyncers.

  ## Proof of Concept

  I verified the bug with the real timeout path, not only with a canceled context.

  The PoC below uses:

  - a real NumGoRoutinesThrottler with capacity 2
  - a real trieSyncer.StartSyncing()
  - an empty trie-node cache and a request handler that never supplies nodes
  - a short sync timeout (1s) so StartSyncing() returns trie.ErrTimeIsOut

  After the first failed sync, one slot remains leaked.
  After the second failed sync, the throttler is exhausted.

  ### PoC test

package syncer

import ( "context" "testing" "time"

    commonmock "github.com/klever-io/klever-go/common/mock"
    corethrottler "github.com/klever-io/klever-go/core/throttler"
    "github.com/klever-io/klever-go/data"
    "github.com/klever-io/klever-go/data/trie"
    triestats "github.com/klever-io/klever-go/data/trie/statistics"
    "github.com/stretchr/testify/require"

)

func newBaseSyncerForTimeoutPOC(t testing.T) baseAccountsSyncer { t.Helper()

    storageManager, err := trie.NewTrieStorageManagerWithoutPruning(commonmock.NewMemDbMock())
    require.NoError(t, err)

    return &baseAccountsSyncer{
            hasher:                    commonmock.HasherMock{},
            marshalizer:               &commonmock.MarshalizerMock{},
            trieSyncers:               make(map[string]data.TrieSyncer),
            dataTries:                 make(map[string]data.Trie),
            trieStorageManager:        storageManager,
            requestHandler:            &commonmock.RequestHandlerStub{},
            timeout:                   time.Second,
            cacher:                    commonmock.NewCacherStub(),
            maxTrieLevelInMemory:      5,
            name:                      "timeout-poc",
            maxHardCapForMissingNodes: 1,
    }

}

func TestPOC_UserAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) { thr, err := corethrottler.NewNumGoRoutinesThrottler(2) require.NoError(t, err)

    s := &userAccountsSyncer{
            baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),
            throttler:          thr,
    }

    err = s.syncDataTrie([]byte("missing-root-1"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.True(t, thr.CanProcess())

    err = s.syncDataTrie([]byte("missing-root-2"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.False(t, thr.CanProcess())

}

func TestPOC_KappAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) { thr, err := corethrottler.NewNumGoRoutinesThrottler(2) require.NoError(t, err)

    s := &kappAccountsSyncer{
            baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),
            throttler:          thr,
    }

    err = s.syncDataTrie([]byte("missing-root-1"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.True(t, thr.CanProcess())

    err = s.syncDataTrie([]byte("missing-root-2"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.False(t, thr.CanProcess())

}

  ### Command used

go test ./data/syncer -run 'TestPOC_(User|Kapp)AccountsSyncer_LeaksThrottlerSlotOnTrieTimeout' -count=1

  ### Result

ok github.com/klever-io/klever-go/data/syncer 4.005s

  This confirms the leak with the real timeout path from trieSyncer.StartSyncing().

  ## Impact

  An attacker who can repeatedly cause trie-node sync failures or timeouts during bootstrap can consume the bounded sync throttler until no capacity
  remains.

  Once enough slots are leaked:

  - additional account-data trie sync attempts stop making progress
  - the parent loop waits until context timeout
  - SyncAccounts() fails
  - epoch bootstrap fails

  This is a core node availability issue. It affects fresh/restarting nodes and validators that need to bootstrap or resync state.

  This is not a theoretical issue:

  - StartSyncing() performs network-dependent trie-node retrieval
  - it already has explicit timeout / failure paths
  - the leaked throttler slots are confirmed by runtime PoC

  ## Recommended Fix

  Release the slot with defer immediately after StartProcessing() and cancel the defer only if ownership is intentionally transferred, which is not the
  case here.

  Example fix pattern:

func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error { u.throttler.StartProcessing() defer u.throttler.EndProcessing()

  u.syncerMutex.Lock()
  defer u.syncerMutex.Unlock()

  if _, ok := u.dataTries[string(rootHash)]; ok {
      return nil
  }

  dataTrie, err := trie.NewTrie(...)
  if err != nil {
      return err
  }

  trieSyncer, err := trie.NewTrieSyncer(arg)
  if err != nil {
      return err
  }

  u.trieSyncers[string(rootHash)] = trieSyncer
  return trieSyncer.StartSyncing(rootHash, ctx)

} ``` The same pattern should be applied to:

data/syncer/userAccountsSyncer.go
data/syncer/kappAccountsSyncer.go

## References

data/syncer/userAccountsSyncer.go
data/syncer/kappAccountsSyncer.go
data/trie/sync.go
core/throttler/numGoRoutinesThrottler.go
core/bootstrap/process.go
SECURITY.md

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T16:40:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "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(\u0026ngrt.counter)\n      return valCounter \u003c ngrt.max\n  }\n\n  func (ngrt *NumGoRoutinesThrottler) StartProcessing() {\n      atomic.AddInt32(\u0026ngrt.counter, 1)\n  }\n\n  func (ngrt *NumGoRoutinesThrottler) EndProcessing() {\n      atomic.AddInt32(\u0026ngrt.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 \u003c-time.After(timeBetweenRetries):\n          continue\n      case \u003c-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 \u0026baseAccountsSyncer{\n                hasher:                    commonmock.HasherMock{},\n                marshalizer:               \u0026commonmock.MarshalizerMock{},\n                trieSyncers:               make(map[string]data.TrieSyncer),\n                dataTries:                 make(map[string]data.Trie),\n                trieStorageManager:        storageManager,\n                requestHandler:            \u0026commonmock.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 := \u0026userAccountsSyncer{\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 := \u0026kappAccountsSyncer{\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 \u0027TestPOC_(User|Kapp)AccountsSyncer_LeaksThrottlerSlotOnTrieTimeout\u0027 -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",
  "id": "GHSA-fw38-pc54-jvx9",
  "modified": "2026-06-05T16:40:40Z",
  "published": "2026-06-05T16:40:40Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

CVE-2026-49343 (GCVE-0-2026-49343)

GHSA-FW38-PC54-JVX9

Summary

Tags

Sightings

Nomenclature