CVE-2026-49343: Klever-Go KVM Denial of Service Vulnerability

MODERATE
Advisory Identifier: GHSA-fw38-pc54-jvx9
CVSS 5.9
CWE-400 CWE-772
Published
Advisory Summary

CVE-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

CVE Identifier CVE-2026-49343
GHSA Identifier GHSA-fw38-pc54-jvx9
Severity MODERATE
CVSS v3.1 Base Score 5.9
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product Klever-Go KVM
Package Ecosystem Go
Published Date
Last Updated

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).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (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.

github.com/klever-io/klever-go fixed: 1.7.18
Upgrade github.com/klever-io/klever-go to 1.7.18
Verify Direct and Transitive Dependencies

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

## 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

CVE-2026-49343 Affected Klever-Go KVM Versions

1 component(s)
Fixed Versions:
1.7.18
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?
CVE-2026-49343 is a security vulnerability in Klever-Go KVM involving Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS under CWE-400: Uncontrolled Resource Consumption.
Which Klever-Go KVM versions are affected?
Affected versions include releases prior to 1.7.18 across affected packages: github.com/klever-io/klever-go.
What version fixes CVE-2026-49343?
Upgrading to 1.7.18 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/klever-io/klever-go affected?
Yes, github.com/klever-io/klever-go is affected in releases prior to 1.7.18. Upgrade your dependency to 1.7.18 or later.
What is the CVSS score of CVE-2026-49343?
CVE-2026-49343 has a CVSS v3.1 base score of 5.9 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2026-49343?
CVE-2026-49343 is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check Go dependencies for CVE-2026-49343?
Run the dependency tree command: 'inspect dependencies for github.com/klever-io/klever-go'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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
  }
}