<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 11:31:51 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-352287</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-352287</link>
      <description>EUVD-2026-352287</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-352287</guid>
    </item>
    <item>
      <title>fkie_cve-2026-49343</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-49343</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-49343</guid>
    </item>
    <item>
      <title>GHSA-fw38-pc54-jvx9 — Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-fw38-pc54-jvx9</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/klever-io/klever-go&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Affected Components&lt;/p&gt;
&lt;p&gt;- `data/syncer/userAccountsSyncer.go`
  - `data/syncer/kappAccountsSyncer.go`
  - `data/trie/sync.go`
  - `core/throttler/numGoRoutinesThrottler.go`
  - `core/bootstrap/process.go`&lt;/p&gt;
&lt;p&gt;## Affected Version&lt;/p&gt;
&lt;p&gt;Verified on:
  - `develop` HEAD `9640d63`&lt;/p&gt;
&lt;p&gt;Please check whether the same code is present in supported `1.7.x` releases.&lt;/p&gt;
&lt;p&gt;## Suggested Severity&lt;/p&gt;
&lt;p&gt;High&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;### Root Cause&lt;/p&gt;
&lt;p&gt;Both account-data syncers call `StartProcessing()` before creating / starting the trie syncer, but they only call `EndProcessing()` on the success path
  and on the duplica…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/klever-io/klever-go&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Affected Components&lt;/p&gt;
&lt;p&gt;- `data/syncer/userAccountsSyncer.go`
  - `data/syncer/kappAccountsSyncer.go`
  - `data/trie/sync.go`
  - `core/throttler/numGoRoutinesThrottler.go`
  - `core/bootstrap/process.go`&lt;/p&gt;
&lt;p&gt;## Affected Version&lt;/p&gt;
&lt;p&gt;Verified on:
  - `develop` HEAD `9640d63`&lt;/p&gt;
&lt;p&gt;Please check whether the same code is present in supported `1.7.x` releases.&lt;/p&gt;
&lt;p&gt;## Suggested Severity&lt;/p&gt;
&lt;p&gt;High&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;### Root Cause&lt;/p&gt;
&lt;p&gt;Both account-data syncers call `StartProcessing()` before creating / starting the trie syncer, but they only call `EndProcessing()` on the success path
  and on the duplica…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-fw38-pc54-jvx9</guid>
    </item>
  </channel>
</rss>
