CVE-2026-49343

This vulnerability allows an attacker to permanently disable trie synchronization on a node by exploiting a resource leak in the throttler that manages concurrent trie operations. The core issue is a classic paired-call-site bug: StartProcessing() acquires a throttler slot, but on certain error paths — specifically network timeouts during bootstrap or catch-up sync — the corresponding EndProcessing() call is never executed. Once slots are consumed, they are never reclaimed. A node that experiences multiple timeout errors during trie sync will permanently exhaust its throttler capacity and become unable to sync, effectively bricked until manual intervention. The critical exposure window is during bootstrap, restart after outage, validator rotation, or any catch-up sync — precisely the moments when trie-node timeouts are most likely even without deliberate attack. An attacker doesn't need to sustain a DoS; they need only create enough network degradation during one of these vulnerable moments to trigger the timeout error path, after which the node does the rest by aborting bootstrap and leaking the slot. Check your deployment immediately: if you're running Klever-Go versions before 1.7.18, you are vulnerable. But patching alone is insufficient. The StartProcessing/EndProcessing pattern appears in multiple sync paths (syncDataTrie via syncUserAccountsState and syncKappAccountsState), and the fix may have addressed only the known instances. Run a code audit for every StartProcessing() call site in your codebase and trace each control flow to verify EndProcessing() is called on all paths — success, early return, and every possible error from opaque external dependencies. The trie package is a third-party dependency; NewTrie(), NewTrieSyncer(), and StartSyncing() can all fail in ways the caller must handle, and missing even one path is sufficient to cause this bug. The deeper concern is structural: this pattern requires perfect enumeration of error types at every call site, forever. The API design makes correct usage non-obvious — requiring manual slot tracking across opaque boundaries — while making the incorrect usage path easy. Consider whether your throttler can implement self-healing behavior (reclaiming slots from failed operations after a timeout) or whether StartProcessing can be moved inside abstraction boundaries where paired calls can be guaranteed. Otherwise, you are one missed error handler away from the next CVE in this lineage.

Reviewed through automated stages and approved by a human before publication.