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 CNA under the mitre root

CNA scorecard C 72/100 over 7877 records in the last 180 days details

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	CPE status
klever-io	klever-go	Affected: < 1.7.18	guessed

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-11-09",
      "epss": "0.00412",
      "percentile": "0.35764"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "klever-go",
                "vendor": "klever-io",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003c 1.7.18"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "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."
          },
          {
            "lang": "es",
            "value": "Klever-Go es la implementaci\u00f3n en Go del protocolo de cadena de bloques Klever. En versiones anteriores a la 1.7.18, los sincronizadores de trie de datos de cuenta son vulnerables a una falla de agotamiento de recursos que filtra ranuras de limitador acotado en rutas de error. En syncDataTrie() (tanto en userAccountsSyncer.go como en kappAccountsSyncer.go), StartProcessing() reserva una ranura del NumGoRoutinesThrottler, pero el EndProcessing() correspondiente solo se llama en la ruta de \u00e9xito y en el retorno anticipado por ra\u00edz duplicada. Como resultado, cualquier error de trie.NewTrie(), trie.NewTrieSyncer() o trieSyncer.StartSyncing() (incluida la ruta de tiempo de espera dependiente de la red) consume permanentemente una ranura durante la vida \u00fatil del limitador. Un atacante que puede causar repetidamente fallas de sincronizaci\u00f3n o tiempos de espera de nodos trie durante el arranque puede agotar el limitador acotado, despu\u00e9s de lo cual las sincronizaciones posteriores de trie de datos de cuenta dejan de progresar y SyncAccounts() devuelve un tiempo de espera. Debido a que el arranque de \u00e9poca en syncUserAccountsState() y syncKappAccountsState() aborta ante cualquier error de este tipo, esto hace que el arranque falle, un problema central de disponibilidad que afecta a nodos y validadores nuevos, que se reinician o que se resincronizan. Este problema se corrige en la versi\u00f3n 1.7.18."
          }
        ],
        "id": "CVE-2026-49343",
        "lastModified": "2026-10-24T16:10:00.153",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "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"
              },
              "exploitabilityScore": 2.2,
              "impactScore": 3.6,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-49343",
                "options": [
                  {
                    "exploitation": "poc"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-13T18:40:07.764602Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-08-07T23:17:04.450",
        "references": [
          {
            "source": "security-advisories@github.com",
            "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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
            "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-400"
              },
              {
                "lang": "en",
                "value": "CWE-772"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "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:39:49.603Z",
              "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"
    }
  }
}

FKIE_CVE-2026-49343

Vulnerability from fkie_nvd - Published: 2026-08-07 23:17 - Updated: 2026-10-24 16:10

Severity

5.9 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/klever-io/klever-go/releases/tag/v1.7.18
	security-advisories@github.com	https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9
	134c704f-9b21-4f2e-91b3-4a467353bcc0	https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "klever-go",
          "vendor": "klever-io",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.7.18"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "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."
    },
    {
      "lang": "es",
      "value": "Klever-Go es la implementaci\u00f3n en Go del protocolo de cadena de bloques Klever. En versiones anteriores a la 1.7.18, los sincronizadores de trie de datos de cuenta son vulnerables a una falla de agotamiento de recursos que filtra ranuras de limitador acotado en rutas de error. En syncDataTrie() (tanto en userAccountsSyncer.go como en kappAccountsSyncer.go), StartProcessing() reserva una ranura del NumGoRoutinesThrottler, pero el EndProcessing() correspondiente solo se llama en la ruta de \u00e9xito y en el retorno anticipado por ra\u00edz duplicada. Como resultado, cualquier error de trie.NewTrie(), trie.NewTrieSyncer() o trieSyncer.StartSyncing() (incluida la ruta de tiempo de espera dependiente de la red) consume permanentemente una ranura durante la vida \u00fatil del limitador. Un atacante que puede causar repetidamente fallas de sincronizaci\u00f3n o tiempos de espera de nodos trie durante el arranque puede agotar el limitador acotado, despu\u00e9s de lo cual las sincronizaciones posteriores de trie de datos de cuenta dejan de progresar y SyncAccounts() devuelve un tiempo de espera. Debido a que el arranque de \u00e9poca en syncUserAccountsState() y syncKappAccountsState() aborta ante cualquier error de este tipo, esto hace que el arranque falle, un problema central de disponibilidad que afecta a nodos y validadores nuevos, que se reinician o que se resincronizan. Este problema se corrige en la versi\u00f3n 1.7.18."
    }
  ],
  "id": "CVE-2026-49343",
  "lastModified": "2026-10-24T16:10:00.153",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "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"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 3.6,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-49343",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-13T18:40:07.764602Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-07T23:17:04.450",
  "references": [
    {
      "source": "security-advisories@github.com",
      "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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-400"
        },
        {
          "lang": "en",
          "value": "CWE-772"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

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

FKIE_CVE-2026-49343

GHSA-FW38-PC54-JVX9

Summary

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour